Chris McDonough wrote:
  - Institute a policy that all distributions that are released to the
    cheeseshop should be installable via "easy_install".  IMO, if they
    are not installable this way, they should not be released to the
    cheeseshop, given the larger Python community's expectations.


  - Figure out why buildout can (apparently) qsuccesfully install
    dependencies of currently failing zope.* eggs while easy_install
    can't.  I probably won't be able to do this.

Because most buildouts specifically point to using find-links (so that way the necessary egg that's missing from PyPI is found), or they pin down the version of zope.traversing.

  - Ditch the idea of releasing separate distributions for each
    package in


    The individual eggs typically can't be used
    outside of a zope appserver installation (and if they can, they
    probably shouldn't be in "", they should be in "zope" or
    they should be their own top-level package), and the
    "namespaciness" of is suspect when it's unlikely that
    anyone who is not a Zope committer will release a distribution
    which makes use of that namespace package.  Their current
    overgranularity makes distributing them as separate eggs and
    releasing them to the cheeseshop a form of "cheeseshop pollution",
    especially given that so few of them can actually currently be
    installed using easy_install or " install".  If cheeseshop
    is going to continue to be used as the index, I'd suggest creating
    a top-level svn module with a single in
    containing all the packages that are meant to go into
    Version the resulting "" distribution as necessary instead
    of versioning many more granular "*" distros.  It's OK if
    some people don't use some of the functionality in the resulting
    egg, just toss everything in.

We can (and should) do that... almost :). For ages, the package has been treated as a namespace package because it always contained stuff that was releasable and stuff that wasn't (e.g. or were experiments that probably shouldn't have been committed there in the first place, but alas, it happened).

I don't think we should start releasing stuff that isn't in a releasable state.

    There is precedent here in the
    Paste distribution.  It has many submodules and does many things,
    but it comes in the form of a single egg.

Except that PasteScript and PasteDeploy are separate, which is just weird, especially considering the awkward naming of the eggs...

    Yes, you lose the
    ability to make a bugfix in one subpackage and release it, but
    IIRC the intent is to trim down anyway, pushing
    libraryish things out to top-level or zope.* packages.

That *was* the plan at least. We moved several packages in the Zope 3.2 -> 3.3 upgrade, but a lot of people complained, so we pretty much stopped doing that. Except when recently the Python parts of, were moved to zope.securitypolicy, zope.session in an attempt to be able to reuse the Python stuff without getting the browser views.

 - Who's in charge?  Whomever you might be, to what extent do you
   agree/disagree with the above suggestions?  If you agree with any,
   how can I help fix things?

 - I'm unsure how anybody is able to install Zope 3 right now using
   eggs, unless there's some fundamental difference in the way
   easy_install resolves dependencies vs. buildout.  I have not looked
   at how Stephan's KGS works yet, though, so I'm sure I'm just
   missing some magic.

 - We should consider fixing setuptools install to detect conflicts
   before attempting to install anything.


   The current regime of "find
   conflicts halfway through an install" is IMO untenable in the long
   term for using eggs as a distribution mechanism.  This may mean a
   very invasive change to both the package index and the client
   software, though.

Yup. The problem is that people run custom indexes locally so setuptools would have to be able to deal with different kinds of index implementations.
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to