b423292cd0
The release of pip10 has shown up a few issues here Firstly, pip10 now refuses to overwrite distutils installed packages, which includes "python-virtualenv" on centos. History has shown us that we want the packages installed and overwritten, to avoid the packages coming back and messing things up. Pre-install all the packages, then list the files in the packages with "rpm" directly and remove them. This way pip is happy to install. We need to take better account of the package names for this; on Fedora things have switch to "python2-virtualenv" instead of "python-virtualenv" and we can't use an alias to list the package contents. This also highlighted that python2-pip is in EPEL for centos, so enable that when we install it. Make the epel element a no-op for non centos/rhe distros. There is a related change in recent fedora that python3 now installs binaries into /usr/local/bin. There are commented swizzles in here to ensure we retain the status quo of "pip" and "virtualenv" both being python2 based, with the python3 versions being called explicitly "pip3" and "virtualenv3" respectively. Change-Id: I2ffdd9f615ae6b00428c17249e4f216774991b99 |
||
---|---|---|
.. | ||
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=package Source 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 mytool To install a python2 tool from pip:: # python2 -m pip install mytool In 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.