
This partially reverts commit 3f961ce202d7d24e2944de09636b35cec9c13bf6. This alternative installs wheel with the ensure-pip role instead of in a separate role. wheel is very closely linked with pip install operations so this isn't a large overreach of the role. I suggest this for several reasons; firstly the python-wheel role doesn't try to install packages, so we end up with mixed system pip and upstream versions of wheel most of the time. This is the type of thing that has proven problematic in the past. It also installs via pip --user; something we've already had problems with tox when for various reasons roles want to run this as non-zuul user. Using ensure-pip we keep the packaged versions together. [1] did try to install wheel with root, but during runtime which didn't work due to sudo being revoked. This should work for the existing build-python-release job, because it already includes ensure-pip in pre-run via playbooks/python/pre.yaml I believe our conclusion on the ensure-* roles was that requiring root/become: for installation is OK, but we should have a no-op path if the tools are found. This is consistent with that approach (i.e. if you want wheel and can't do sudo, you should pre-install it on your image using whatever you build that with). This adds a check to the existing "is pip installed" check to also check if wheel packages are available. If not we trigger the install path. This revealed some issues with RedHat.yaml -- we can always install Python 3 (packages available for CentOS 7) so remove that check, and if Ansible is running under Python 2; ensure we install the dependencies too (not only if it is forced). Update the documentation to describe that it will enable support for bdist_wheel, and add a basic sanity test that wheels are produced by pip. The existing build-python-release job is kept; although it is modified to use the playbooks/python/pre.yaml playbook as the build job does. Change-Id: I2ab11bb45b6b2a49d54db39195228ab40141185c [1] https://review.opendev.org/#/c/736001/5/roles/build-python-release/tasks/main.yaml
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.
This role will also wheel
components sufficient to run
bdist_wheel
builds or pip wheel
on a source
tree.
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).