Open Stack

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.
-- 
Jeremy Stanley