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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
