[Zope3-dev] Re: Known working sets II [was: Eggification redux]

[Martin Aspeli]

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