[openstack-dev] [infra][qa][requirements] Pip 10 is on the way
Clark Boylan
cboylan at sapwetik.org
Thu Apr 5 21:38:15 UTC 2018
On Thu, Apr 5, 2018, at 1:27 PM, Clark Boylan wrote:
> The other major issue we've run into is that nova file injection (which
> is tested by tempest) seems to require either libguestfs or nbd.
> libguestfs bindings for python aren't available on pypi and instead we
> get them from system packaging. This means if we want libguestfs support
> we have to enable system site packages when using virtualenvs. The
> alternative is to use nbd which apparently isn't preferred by nova and
> doesn't work under current devstack anyways.
>
> Why is this a problem? Well the new pip10 behavior that breaks devstack
> is pip10's refusable to remove distutils installed packages. Distro
> packages by and large are distutils packaged which means if you mix
> system packages and pip installed packages there is a good chance
> something will break (and it does break for current devstack). I'm not
> sure that using a virtualenv with system site packages enabled will
> sufficiently protect us from this case (but we should test it further).
> Also it feels wrong to enable system packages in a virtualenv if the
> entire point is avoiding system python packages.
Good news everyone, http://logs.openstack.org/74/559174/1/check/tempest-full-py3/4c5548f/job-output.txt.gz#_2018-04-05_21_26_36_669943 shows the pip10 appears to do the right thing with a virtualenv using system-site-package option when attempting to install a newer version of a package that would require being deleted if done on the system python proper.
It determines there is an existing package, that it is outside the env and it cannot uninstall it, then installs a newer version of the package anyways.
If you look later in the job run you'll see it fails in the system python context on this same package, http://logs.openstack.org/74/559174/1/check/tempest-full-py3/4c5548f/job-output.txt.gz#_2018-04-05_21_29_31_399895.
I think that means this is a viable workaround for us even if it isn't ideal.
Clark
More information about the OpenStack-dev
mailing list