On Fri, May 8, 2015 at 4:23 AM, Sean Dague <s...@dague.net> wrote: > On 05/08/2015 07:13 AM, Robert Collins wrote: > > On 8 May 2015 at 22:54, Sean Dague <s...@dague.net> wrote: > >> I'm slightly confused how we got there, because we do try to install > >> everything all at once in the test jobs - > >> > http://logs.openstack.org/83/181083/1/check/check-requirements-integration-dsvm/4effcf7/console.html#_2015-05-07_17_49_26_699 > >> > >> And it seemed to work, you can find similar lines in previous changes as > >> well. That was specifically added as a check for these kinds of issues. > >> Is this a race in the resolution? > > > > What resolution :). > > > > So what happens with pip install -r > > /opt/stack/new/requirements/global-requirements.txt is that the > > constraints in that file are all immediately put into pip's state, > > including oslo.config >= 1.11.0, and then all other constraints that > > reference to oslo.config are simply ignored. this is 1b (and 2a) on > > https://github.com/pypa/pip/issues/988. > > > > IOW we haven't been testing what we've thought we've been testing. > > What we've been testing is that 'python setup.py install X' for X in > > global-requirements.txt works, which sadly doesn't tell us a lot at > > all. > > > > So, as I have a working (but unpolished) resolver, when I try to do > > the same thing, it chews away at the problem and concludes that no, it > > can't do it - because its no longer ignoring the additional > > constraints. > > > > To get out of the hole, we might consider using pip-compile now as a > > warning job - if it can succeed we'll be able to be reasonably > > confident that pip itself will succeed once the resolver is merged. > > > > The resolver I have doesn't preserve the '1b' feature at all at this > > point, and we're going to need to find a way to separate out 'I want > > X' from 'I want X and I know better than you', which will let folk get > > into tasty tasty trouble (like we're in now). > > Gotcha, so, yes, so the subtleties of pip were lost here. > > Instead of using another tool, could we make a version of this job pull > and use the prerelease version of your pip code. Then we can run the > same tests and fix them in a non voting job against this code that has > not yet released. > > Once we are actually testing that all of global requirements is co-installable will we end up with even more cases like this? Or is this just an artifact of capping fro kilo? https://review.openstack.org/#/c/166377/
> -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
