[Zope-dev] trying out the buildout-based Zope 2.12...

[Jim Fulton]

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