Open Stack

Good point, we really need a better dependency resolver/installer...

Jeremy Stanley wrote:
> On 2014-11-17 16:41:02 -0800 (-0800), Joshua Harlow wrote:
>> Robert Collins wrote:
>> [...]
>>> That said, making requirements be capped and auto adjust upwards would
>>> be extremely useful IMO, but its a chunk of work;
>>>   - we need the transitive dependencies listed, not just direct dependencies
>> Wouldn't a pip install of the requirements.txt from the requirements repo
>> itself get this? That would tell pip to download all the things and there
>> transitive dependencies (aka step #1).
>>
>>>   - we need a thing to find possible upgrades and propose bumps
>> This is an analysis of the $ pip freeze after installing into that
>> virtualenv (aka step #2)?
> [...]
>
> Something to keep in mind here is that just asking pip to install a
> list of 150 packages at particular versions doesn't actually get you
> that. You can't ever really cap your transitive dependencies
> effectively because they are transitive, so pip will ignore what
> you've asked for if some other package you subsequently install
> wants a different version of the same. For this reason, the result
> is also highly dependent on the order in which you list these
> dependencies.
>
> If your project lists dependencies on A<X B<Y and then project B
> which you don't control lists a dependency on A>X, you'll get A>X
> B<Y as the end result.
>
> Probably the closest we can come is to try to iteratively identify a
> set of specific versions which when requested are the actual
> versions that end up being installed, and then test and report on
> the effects of deviating any one of those versions upward to the
> next available version. I posit this will at times lead to
> multi-point attractors rather than static solutions, with an
> increasing likelihood as the list of dependencies grows.