[nova] openstack-tox-lower-constraints broken

Sean Mooney smooney at redhat.com
Tue Aug 4 13:11:03 UTC 2020

On Tue, 2020-08-04 at 12:39 +0000, Jeremy Stanley wrote:
> On 2020-08-04 14:26:06 +0200 (+0200), Gorka Eguileor wrote:
> [...]
> > Looking at one of my patches I see that the right version of
> > dogpile.cache==0.6.5 is being installed [1], but then at another step we
> > download [2] and install [3] version 1.0.1, and we can see that pip is
> > actually complaining that we have incompatibilities [4].
> > 
> > As far as I can see this is because in that pip install we requested to
> > wipe existing installed packages [6] and we are not passing any
> > constraints in that call.
> > 
> > I don't know why or where we are doing that though.
> [...]
> Yes, I started digging into this yesterday too. It's affecting all
> tox jobs, not just lower-constraints jobs (upper-constraints is
> close enough to unconstrained that this isn't immediately apparent
> for master branch jobs, but the divergence becomes obvious in stable
> branch jobs and it's breaking lots of them). It seems this started
> roughly a week ago.
> I don't think we're explicitly doing it, this seems to be a behavior
> baked into tox itself. Most projects are currently applying
> constraints via the deps parameter in their tox.ini, and tox appears
> to invoke pip twice: once to install your deps, and then a second
> time to install the project being tested. The latter phase does not
> use the deps parameter, and so no constraints get applied.
> We might be able to work around this by going back to overriding
> install_command and putting the -c option there instead,
right so stephen asked me to remove that override in one of my recent patches to os-vif that is
under view since he made the comment the command we were using was more or less the same as the default
we currently set teh -c in deps.
so if i understand the workaound correclty we woudl add -c  {env:CONSTRAINTS_OPT} to install_command
so "install_command = pip install -U {opts} {packages} -c {env:CONSTRAINTS_OPT}" in our case and
then for the lower contriats jobs in stead of 

deps =

we would do 
setenv =
deps =

that way we can keep the same install command for both but use the correct constrint file.
>  but I
> haven't had an opportunity to test that theory yet. If anyone else
> has time to pursue this line of investigation, I'd be curious to
> hear whether it helps.

More information about the openstack-discuss mailing list