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. >>> While: >>> 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 > "zope.app.security==3.7.0" > 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 > huge).
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? Jim -- Jim Fulton Zope Corporation _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )