On Mar 29, 2009, at 3:28 AM, Dieter Maurer wrote:
> Chris Withers wrote at 2009-3-27 16:02 -0500:
>>> Got zope.principalregistry 3.7.0.
>>> Installing zopetest.
>>> Error: There is a version conflict.
>>> We already have: zope.component 3.5.1
>>> but zope.app.security 3.7.0 requires 'zope.component>=3.6.0'.
>> Okay, so I thought I'd be smart and try the following buildout.cfg:
>> What the hell is zope.app.security 3.7.0 doing being dragged down?
>> Is this a buildout snafu? Jim?
> I fear we will have to learn to live with version conflicts
> until we are ready to pin each and every version used, either
> in the buildout itself or via a KGS (Known Good Set index).
> If we let "buildout/setuptools" decide which version to use,
> there is a good chance that it gets it wrong.
> The problem would be far smaller if "setuptools" (yes, this is
> the major component to blame in this case, not "buildout")
> would first construct the complete dependency graph and then
> try to search a global solution. Unfortunately, "setuptools"
> resolves dependancies incrementally (not globally): when
> it has to handle a dependency, it tries to find a distribution
> satisfying the requirements taking into account the distributions
> it already has -- but not the dependency requirements it will
> also have to satisfy in a short time. This way, it may take
> a distribution that after a short while will conflict with
> another dependancy requirement.
> Your observation above might (other chains are possible) result from:
> Some dependency specifies: "zope.component==3.5.1".
> Later some dependancy specifies: "zope.app.security"
> "setuptools" looks what distribution it can choose.
> Lacking a more specific prescription, it uses the newest
> one "zope.app.security==3.7.0".
> Later, it tries to resolve the dependencies of
> and finds "zope.component==3.6.0". Conflict!
> To avoid the conflict, "setuptools" would need to backtrack and
> revise its distribution decision for "zope.app.security"
> or alternatively first build the complete dependency graph and
> search a global solution.
> However, finding such a global solution requires a complex algorithm
> at least when efficiency is important (which probably is
> the case as the dependency graphs for larger applications will be
I think that's a good summary of the issue.
> Thus: I appreaciate much your wish to solve this problem but expect
> that it will be quite complex.
I still think it's worth trying.
I think an implementation of a better dependency resolution strategy in
buildout would be a good place to start. I think some limited
backtracking could go a long way. Anyone interested in working on this?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -