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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
