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