Jim Fulton wrote:

Would it be possible for buildout to retrieve such a list from an egg
if it's maintained as an extra, made-up setup.py variable? I just
tried this, but it doesn't seem to be stored in egg-info.


In theory, but not today. Your use case would be better served by adding a way to tell buildout to use a package version even if it violates some requirements,

FWIW, Plone has this problem too - we have a number of packages which are eggs, and some which are Zope 2 products.

Our "tactical" solution is plone.recipe.plone[1]. Basically, this has a known-good working set of versions and will peg to releases (using the == version specifier). However, the recipe will also allow you to override versions by explicitly specifying eggs. That's good for developers and power users who need to use a later version, but we "strongly prefer" known good working sets.

Of course, plone.recipe.plone has some problems (mainly, it's a product-specific recipe, and we need to release a version of the recipe for each version of Plone), but I could see something like this working (forgetting for a moment that Plone also has non-egg dependencies to think about):

 - We release the meta-egg "Plone", version 3.0

- In its setup.py I have a set of dependencies (the known-good working set) which works for Plone 3.0, our supported, proper release. This could just be the normal install_requires dance, with == dependencies as the norm.

- Buildout allows me to override some of those eggs with some specific syntax, e.g.:

 [eggs]
 ...
 recipe = zc.recipe.egg
 eggs =
   Plone==3.0            # get all of Plone 3.0's eggs as hard versions
   plone.portlets==3.1 ! # override the dependency from Plone 3.0

The ! syntax here is an invention, but something like it - it's now explicit that I'm overriding and I know what I'm doing. Without it, buildout would complain about a version conflict.

Further, if I had both Plone and FooBar in the eggs list, and both depended on (possibly different) versions of plone.portlets, the ! syntax would allow me to explicitly override *both*, if I knew that really this version was compatible with both.

Presumably, setuptools could support this behaviour and syntax natively as well one day, but we could get it into buildout first.

I like this approach better than the HTTP-fetched 'versions' spec because (a) it doesn't depend on an external connection and we don't have to maintain some URL where this is stored (a lot of smaller projects may not have a sensible place to even make it available from) (b) it's part of the Plone meta-egg, which we could release to the Cheese Shop as a meta-egg that lets people get a "known good" Plone (c) other packages can simply depend on Plone==3.0 and get the normal behaviour.

This doesn't really address Tres' point about collecting "known good" sets in a more decentralised, graph-like way, but it ought to work for people (like Zope, Grok, CMF and Plone) that want to provide their users with a solid release, without making it impossible to sidestep it if you know what you're doing.

Martin

[1] http://cheeseshop.python.org/pypi/plone.recipe.plone

--
Acquisition is a jealous mistress

_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to