[Distutils] Reverse dependencies

[Phillip J. Eby]

At 07:17 PM 5/13/2007 +0100, Martin Aspeli wrote:
>Phillip J. Eby wrote:
> > At 06:11 PM 5/13/2007 +0100, Martin Aspeli wrote:
> >> Phillip J. Eby wrote:
> >>> At 05:00 PM 5/13/2007 +0100, Martin Aspeli wrote:
> >>>> But is there any support for such declarative "reverse" dependencies?
> >>> Sort of, in a very limited way.  You'll get a version compatibility
> >>> error if you depend on say, Plone<3 and your dependency depends on
> >>> Plone>=3.1, for example.  But there's no backtracking to resolve
> >>> this, so the minute it happens your installation is basically dead
> >>> until you get rid of the problematic package.
> >> Comforting. :-)
> >>
> >> Do you think it'd be a useful feature? I realise it may not be
> >> immediately trivial to add. ;)
> >
> > No kidding.  I believe it's potentially NP-complete, which is why I
> > only implemented a non-backtracking version that always goes for the
> > highest installed version of each package.
> >
> > If somebody else wants to take a look at designing a backtracking
> > algorithm, take a look at the WorkingSet.resolve() method in 
> pkg_resources.
>
>Well, it may not need to be quite so complex, but it might require some
>new spelling. The idea would be to separate declarative platform support
>from general dependency management (a supported platform may not even be
>a direct dependency, only a "known good" combination).
>
>For example, in your.package (the dependency), we could say:
>
>   supported_platforms=["Plone>=3.0<4", "Zope>=2.10<2.11"]
>
>my.app could say something similar;
>
>   supported_platforms=["Plone>=3.0.1<4", "Zope>=2.10.3<2.11"]
>
>You would only need to look for an overlap in the supported platforms.

I don't see how this is different from what I said.  It's still a 
dependency (and dependency conflict), and it requires the same kind 
of backtracking to support handling it.  Thus, I don't see any reason 
to create another kind of dependency for it, because it wouldn't 
actually simplify anything as far as I can tell.