f52b385818
We added this sed in I422490ebe9a9c655552685bc2ff342d288335a9c to avoid installing python2 packages on python3-only systems and thus dragging in all of python2. We made a similar change to python-pip in I7d8ba9300039cce90965410a4e16ca9e711904c3; however we realised that the gate (and other consumers) were relying on this element having installed the python2 & 3 packages for consistency -- otherwise jobs would install the python-pip packages and overwrite the pip-from-source and mess everything up. We reverted that in I419dbdf4682394db68974944af1e5c432f3e0565 and added some clearer notes that this element brings in python2 & 3, and if you want something that doesn't do that then this element isn't for you. However, we never fixed up the virtualenv package install -- currently our Xenial images have a global virtualenv installed from source, but the python-virtualenv packages aren't installed. Thus if a job does "apt-get install python-virtualenv" it overwrites the from-source virtualenv with older parts and again messes everything up. Probably most jobs just call "virtualenv" and assume it is there; however in bringing up some rspec test for puppet I have hit this issue as some modules specify dependencies on the virtualenv packages. Thus install the python-virtualenv AND python3-virtualenv packages in this element. Change-Id: Ia84c38dc3c40a6080e144b563e10abca7dac2881 |
||
|---|---|---|
| .. | ||
| install.d/pip-and-virtualenv-source-install | ||
| test-elements | ||
| element-deps | ||
| package-installs.yaml | ||
| pkg-map | ||
| README.rst | ||
| source-repository-pip-and-virtualenv | ||
pip-and-virtualenv
This element installs pip and virtualenv in the image.
Note
This element setups and Python 2 and Python 3 environment. This means it will bring in python2 packages, so isn't appropriate if you want a python3 only environment.
Package install
If the package installtype is used then these programs are installed
from distribution packages. In this case, pip and
virtualenv will be installed only for the python
version identified by dib-python (i.e. the default python
for the platform).
Distribution packages have worked out name-spacing such that only
python2 or python3 owns common scripts like /usr/bin/pip
(on most platforms, pip refers to python2 pip, and
pip3 refers to python3 pip, although some may choose the
reverse).
To install pip and virtualenv from package:
export DIB_INSTALLTYPE_pip_and_virtualenv=packageSource install
Source install is the default. If the source installtype is used,
pip and virtualenv are installed from the
latest upstream releases.
Source installs from these tools are not name-spaced. It is
inconsistent across platforms if the first or last install gets to own
common scripts like /usr/bin/pip and
virtualenv.
To avoid inconsistency, we firstly install the packaged python 2
and 3 versions of pip and
virtualenv. This prevents a later install of these
distribution packages conflicting with the source install. We then
overwrite pip and virtualenv via
get-pip.py and pip respectively.
The system will be left in the following state:
/usr/bin/pip: python2 pip/usr/bin/pip2: python2 pip (same as prior)/usr/bin/pip3: python3 pip/usr/bin/virtualenv: python2 virtualenv
(note python3 virtualenv script is not
installed, see below)
Source install is supported on limited platforms. See the code, but this includes Ubuntu and RedHat platforms.
Using the tools
Due to the essentially unsolvable problem of "who owns the script",
it is recommended to not call pip or
virtualenv directly. You can directly call them with the
-m argument to the python interpreter you wish to install
with.
For example, to create a python3 environment do:
# python3 -m virtualenv myenv
# myenv/bin/pip install mytoolTo install a python2 tool from pip:
# python2 -m pip install mytoolIn this way, you can always know which interpreter is being used (and affected by) the call.
Ordering
Any element that uses these commands must be designated as 05-* or higher to ensure that they are first installed.