
It turns out the extant comment, removed here, is correct in identifying the problem, but incorrect about the solution. As noted the v8 pip included with Xenial doesn't fall back to PyPi correctly when nodes are configured with mirrors. However, the note about virtualenv upgrading pip is incorrect. This was not tested on our "plain" nodes (this will be added by a follow-on https://review.opendev.org/724776 when it can pass) so virtualenv was picking up the pip installed by the pip-and-virtualenv element. Installing pip from source doesn't really help; in fact it makes things even more confusing because "python3 -m venv" still uses the inbuilt pip from the python-pip-whl package [1]. e.g. root@ubuntu-xenial-plain:~# pip --version pip 20.1 from /usr/local/lib/python3.5/dist-packages/pip (python 3.5) ^ this is installed by get-pip.py root@ubuntu-xenial-plain:~# python3 -m venv test root@ubuntu-xenial-plain:~# ./test/bin/pip --version pip 8.1.1 from /root/test/lib/python3.5/site-packages (python 3.5) ^ it still deploys pip in the venv from the whl and thus will *not* pick up the source pip install. This is a problem on our extant Xenial hosts, so clearly nobody is using it. However, as part of this work we want to standardise other tools we are installing in zuul-jobs to use "python3 -m venv". Thus we want all our platforms need to support a working venv out of the box. The solution proposed here is to install a backport of Bionic's pip 9 into Xenial when using this element. This way, we are still shipping packaged pip on the host and keeping our images as close to plain vanilla upstream as possible, but with almost as small change as we can manage to actually work in our environment. Given the sunsetting lifespan of Xenial, this should require not further maintenance until we are no longer interested in the distro. Because we skip the install phase on nodes with pre-installed pip, we put in a work-around to set "ensure_pip_virtualenv_command" to virtualenv on extant nodes that have been configured with pip-and-virtualenv. We can remove this when we have only "plain" nodes (i.e. no pip-and-virtualenv element) and then we will consistently be using venv's. [1] https://packages.ubuntu.com/xenial/python-pip-whl Change-Id: Id8347b6b09735659a7ed9bbe7f9d2798fbec9620
Ensure pip is available
This role is intended install the requirements for the pip module on hosts.
Jobs that also wish to call pip
via shell commands
directly can also use this to ensure pip
is available.
However, it should be noted that calling pip
is ambiguous
when supporting many platforms. On some platforms it may install the
package under the Python 2 interpreter and in others Python 3. You
should use a qualified name (pip2
or pip3
) to
avoid confusion.
Role Variables
Output Variables
This variable will be set to a command appropriate for general usage with the
pip
modulevirtualenv_command
argument on the host. On Python 3 hosts this will be the inbuiltvenv
module, on Python 2 hosts thevirtualenv
package will be installed (this is avoided on Python 3 hosts as an unnecessary dependency).