[Zope-CMF] Known working sets II [was: Eggification redux]
charlie at begeistert.org
Tue Sep 25 08:40:11 EDT 2007
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
More information about the Zope-CMF