Phillip J. Eby wrote:
> 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.
I won't pretend to have thought this through to very end, but I don't
quite understand why this should be so hard, then.
The algorithm would be something like:
- I support platform Plone, version >= 3.0.1 and < 4
- I am looking for package your.package, version >= 1.0
- The most recent version that satisfies this is 2.1
- Version 2.1 declares it supports Plone >=4, can't use that
- The second-most-recent version that satisfies your.package >= 1.0 is
2.0
- Version 2.0 declares it supports Plone 3.9, okay, we can use that
- Repeat check for Zope
Actually... I see how it could get complicated with lots of platform
dependencies. :)
I wonder if this can't be simplified to the common case where there's
only one "main" platform to worry about, though, e.g. only check "Plone"
from my.app in the case above, but let your.package declare support for
various "known good" configurations, such as "with Plone 3" and "with
Zope 2.10".
One difference to straight dependencies, by the way, is the case where
you support (or a package is known to work with) a platform, without
necessarily needing to depend on it. That may be useful metadata.
I'm mostly just thinking out loud, though. :)
Martin
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
