`python` is `python2.7` but `pip` is `pip3.6`

Environments Multi CPU Architecture
1

I was really stumped by weird issues when building on arm64/ppc64le/s390x in a C/C++ based project which uses some python for post-processing coverage data… Until I finally discovered that python is python2.7 but pip is pip3.6 (click here for an example build). To be specific, I do this in .travis.yml:

addons:
  apt_packages:
    - python            # for code coverage / installing gcovr
    - python-pip        # for code coverage / installing gcovr
    - python-setuptools # for code coverage / installing gcovr
    - python-wheel      # for code coverage / installing gcovr

and the apt-get update log says:

python is already the newest version (2.7.15~rc1-1).
python-pip is already the newest version (9.0.1-2.3~ubuntu1.18.04.1).

so seemingly all is fine… But then later on, I see this:

$ pip --version
pip 19.3.1 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6)
The command "pip --version" exited with 0.
$ python --version
Python 2.7.17

So clearly some python3.6 installation I didn’t ask for pollutes the PATH.

Now, mind you, I am happy to either either python2 or python3, my code should work with both; the problem this mixing. In this case I can adjust my script and hardcode pip2 instead of pip but this is a fragile solution. It would be nice if the base images for these architectures were fixed to address this.

There are plenty other bugs in them, too, of course (see my other recent posts here)

1 Like
2

As of 1/1/2020, Python 2 is now history.

Perhaps it is safer to use python2 -m pip install xyz and python3 -m pip install xyz as discussed at https://snarky.ca/why-you-should-use-python-m-pip

1 Like
3

Thanks for the hint to use python -m pip install, that’s super useful and I’ll use it!

That said, I still think it’s a bug on Travis’ side that the base image has mismatched python and pip binaries.

1 Like