pip: ImportError: No module named build_clib / pip installs setuptools 36.0.1 when directed to install 30.0.0

  • Pip version: 9.0.1
  • Python version: 2.7.13
  • Operating system: Ubuntu 14.04 (on Travis CI)

Description (including what I’ve run):

We test our project on Travis with the minimum Python package versions we specify. A few days ago, it started consistently failing the pip install . for our project, in the setup.py egg_info step. It turns out that running python setup.py egg_info reproduces the same error, as shown here:

python setup.py egg_info
ERROR:root:Error parsing
Traceback (most recent call last):
  File "/home/travis/virtualenv/python2.7.13/lib/python2.7/site-packages/pbr/core.py", line 111, in pbr
    attrs = util.cfg_to_args(path, dist.script_args)
  File "/home/travis/virtualenv/python2.7.13/lib/python2.7/site-packages/pbr/util.py", line 264, in cfg_to_args
    wrap_commands(kwargs)
  File "/home/travis/virtualenv/python2.7.13/lib/python2.7/site-packages/pbr/util.py", line 566, in wrap_commands
    cmdclass = ep.resolve()
  File "/home/travis/virtualenv/python2.7.13/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2293, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
ImportError: No module named build_clib
error in setup command: Error parsing /home/travis/build/zhmcclient/python-zhmcclient/setup.cfg: ImportError: No module named build_clib

This happens on Travis with Ubuntu 14.04 and Python 2.7.13 (it uses a virtuel env).

On a locally set up Ubuntu 14.04 with a manually installed Python 2.7.13, in a virtual env, and with the same Python packages and versions installed in that virtual env, and the same pip version, I was not able to reproduce it so far.

The set of Python packages in the virtual env, when it happens on Travis, is:

funcsigs (1.0.2)
mock (2.0.0)
nose (1.3.7)
numpy (1.13.1)
pbr (1.10.0)
pip (9.0.1)
py (1.4.34)
pytest (3.2.1)
setuptools (36.0.1)
six (1.10.0)
wheel (0.29.0)

With this package state, we then reinstall pip, setuptools, wheel and pbr in single pip install commands, to the desired minimum versions. This is done separately from the project install, in order to make sure the install process itself also uses the minimum versions:

pip install --upgrade pip
pip install -c minimum-constraints.txt pip
pip install -c minimum-constraints.txt setuptools
pip install -c minimum-constraints.txt wheel
pip install -c minimum-constraints.txt pbr

We then install our own project:

pip install -c minimum-constraints.txt .

Looking at the log reveals that the pip install setuptools installs 36.0.1 when asked to install 30.0.0 (via the constraints file):

pip install -c minimum-constraints.txt setuptools
Collecting setuptools===30.0.0 (from -c minimum-constraints.txt (line 21))
  Downloading setuptools-30.0.0-py2.py3-none-any.whl (472kB)
    100% |████████████████████████████████| 481kB 2.4MB/s 
Installing collected packages: setuptools
  Found existing installation: setuptools 36.3.0
    Uninstalling setuptools-36.3.0:
      Successfully uninstalled setuptools-36.3.0
Successfully installed setuptools-36.0.1

A subsequent pip list confirms that 36.0.1 is installed.

Interestingly, installing setuptools===36.0.1 instead of 30.0.0 also shows 36.0.1 as installed but on Travis does not result in the error shown above.

Trying to install setuptools===30.0.0 a second time installs 30.0.0 as it should, and then the error does not show up.

When using the latest available package versions, the error does not show up on Travis.

The error did not show up on Travis until a few days ago.

The error does not show up when using Python 2.7.12 or older on Travis.

We have multiple logs of this on Travis, one that fails and uses the -v option on the pip install setuptools, is here: https://travis-ci.org/zhmcclient/python-zhmcclient/jobs/275007053

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 40 (19 by maintainers)

Most upvoted comments

I’m not sure I can think of a good use case for --ignore-installed, maybe it should just be removed.

Ultimately it probably should be removed, but we need to revamp how our system handles layered installs before we can. Right now if foobar is installed to the system site packages and you try to do pip install --user --upgrade foobar, it will first attempt to uninstall foobar from the system site-packages (assuming there is a newer version) before installing to the user location. That is kind of silly, but the work around is to use --ignore-installed.