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
This is part of the efforts to remove pip-and-virtualenv from our base
images [1].
There are some users who specifically require the virtualenv command
(perhaps, like dib, they have some code that uses the activate_this.py
mechanisms it provides wich venv does not).
This installs the virtualenv package for the currently running
distribution.
One of the main maintenance issues of pip-and-virtualenv is that tried
to ensure that "virtualenv" created a Python 2 environment always by
default. Now that we have Python 3 only distributions like current
Fedora, this is not something we can continue to do (even if we wanted
to, which we don't).
What owns virtualenv and what it produces in our heterogeneous
environment is messy, and I think the best we can do is document it as
done here.
[1] https://docs.opendev.org/opendev/infra-specs/latest/specs/cleanup-test-node-python.html
Change-Id: I97d8bfb970ed2b5aaa02a0813899014c94994066
This role is intended to ensure that the `pip:` module, and jobs that
may wish to use `pip` from the shell, have the necessary requirements.
It is intended as a partial replacement for the pip-and-virtualenv
element in diskimage-builder, which currently pre-installs pip on our
infra CI images during image build.
We wish to remain broady compatible with this element, but not
replicate some of the more problematic areas of its implementation.
By default, this installs the system packages for pip and setuptools
(the latter being a requirement of the Ansible pip module, which
imports it directly, despite pip itself not requiring it).
In this role, we ensure the libraries for the currently running
ansible_python_interpreter version are installed.
There is provision to provide a flag to install the packages directly
from upstream via get-pip.py, although this is not recommended.
Story: #2007386
Task: #39309
Change-Id: Iac2d518a66caf1b801273225f75a0a748412903c
This splits all of the current job and role documentation into
files by subject area so that jobs and roles are easier for users to
find.
This will require that any future new jobs or roles add a line to the
appropriate area of the documentation, since that can no longer be
done automatically. A linter check is added to ensure that every
job and role continue to be documented.
After this refactor, we can begin to enhance the documentation pages
so that they include narrative documentation and subsections.
Change-Id: Ia6f0e89b57e3cb0d7d1745206384c946506d7ea0