Re: [Zope-CMF] Known working sets II [was: Eggification redux]
Am 25.09.2007 um 14:06 schrieb Philipp von Weitershausen: * 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. This sounds essentially similar to what Tres is proposing: an online resource with explicit configuration details. * 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. This sounds like an accident waiting to happen in terms of maintenance. I guess the underlying problem is the move towards the more library- based approach to Zope which makes mixing packages a bit more challenging. I haven't spent a lot of time with the various Linux package managers because most of my unix experience has been with FreeBSD where make install just works, except if you want to install unixODBC and iODBC at the same time ;-) but I have been bitten by different libraries going in different places and incompatabilities between libraries. I've also had some experience with CPAN which always does make test before installing and given the chance of incompatibilities I would hope that any installer would run tests on a temporary install before actually installing anything for real. I don't think any installer should be able to break existing components with default settings. My experiences suggest that I will be installing from source for a while yet. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Known working sets II [was: Eggification redux]
(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 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
