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
