[Zope-CMF] Known working sets II [was: Eggification redux]

[Philipp von Weitershausen]

(Also CCing zope3-dev where the first known working set discussion 
started a while ago)

Tres Seaver wrote:
> This is the "known good" problem.  I'm pretty convinced that adding some
> kind of "PyPI subset", where gardeners for a given "package set" keep
> the list of packages / versions known to work well together, is the only
> way out of this issue.  E.g., a URL like:
> 
>   http://pypi.python.org/pypi/release/zope3.4
> 
> would be usable as an 'index-url' for setuptools:  when used this way,
> setuptools would only find / install eggs from the "gardened" set,
> rather than whatever anyone happened to have uploaded that day.
> 
> If PyPI can't be tweaked to provide such a feature, we may need to come
> up with some kind of mirroring scheme which does allow it.

This is certainly an interesting approach. I'd be curious how you would 
garden this known working set. Martijn makes a pretty good case for 
maintaining such working sets close to the package in question (e.g. the 
grok egg, the Plone egg, etc.).

I see two more solutions:

* A versions.cfg that's loaded via HTTP. zc.buildout actually supports 
this now which makes it quite appealing. Also, far as I know, all major 
deployers of Zope3 that use zc.buildout for deployment use this form of 
pinning egg versions right now, which means it's actually being used out 
there.

* Adding version conflict resolution to zc.buildout and/or setuptools. 
That way you could create meta eggs (e.g. the 'Zope' egg) with '==' 
version specificers (for Grok, the 'grok' egg would function as the meta 
egg as well). If this would cause version conflicts (and they often 
occur in buildout due to the lack of a full dependency tree before 
download), it should be possible to say which egg's versions are 
authoritative.

-- 
http://worldcookery.com -- Professional Zope documentation and training