python boostrap.py fails due to pre-installed setuptools causing version conflict

[chaudum]

git clone --depth=50 git://github.com/crate/crash.git crate/crash
Cloning into 'crate/crash'...
remote: Counting objects: 422, done.
remote: Compressing objects: 100% (204/204), done.
remote: Total 422 (delta 214), reused 367 (delta 172)
Receiving objects: 100% (422/422), 80.38 KiB | 0 bytes/s, done.
Resolving deltas: 100% (214/214), done.
Checking connectivity... done.
$ cd crate/crash
0.10s$ git fetch origin +refs/pull/51/merge:
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 12 (delta 7), reused 6 (delta 1)
Unpacking objects: 100% (12/12), done.
From git://github.com/crate/crash
* branch refs/pull/51/merge -> FETCH_HEAD
$ git checkout -qf FETCH_HEAD
0.01s$ source ~/virtualenv/python3.3/bin/activate
$ python --version
Python 3.3.5
$ pip --version
pip 6.0.7 from /home/travis/virtualenv/python3.3.5/lib/python3.3/site-packages (python 3.3)
1.30s$ python bootstrap.py
Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-12.1.zip
Extracting in /tmp/tmpeqvl0x
Now working in /tmp/tmpeqvl0x/setuptools-12.1
Building a Setuptools egg in /tmp/tmp4uaaq8
/tmp/tmp4uaaq8/setuptools-12.1-py3.3.egg
Traceback (most recent call last):
File "<string>", line 162, in use_setuptools
File "/home/travis/virtualenv/python3.3.5/lib/python3.3/site-packages/pkg_resources/__init__.py", line 918, in require
needed = self.resolve(parse_requirements(requirements))
File "/home/travis/virtualenv/python3.3.5/lib/python3.3/site-packages/pkg_resources/__init__.py", line 810, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (setuptools 12.0.5 (/home/travis/virtualenv/python3.3.5/lib/python3.3/site-packages), Requirement.parse('setuptools>=12.1'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "bootstrap.py", line 92, in <module>
ez['use_setuptools'](**setup_args)
File "<string>", line 174, in use_setuptools
File "<string>", line 129, in _do_download
File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked
File "/tmp/tmp4uaaq8/setuptools-12.1-py3.3.egg/setuptools/__init__.py", line 11, in <module>
File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked
File "/tmp/tmp4uaaq8/setuptools-12.1-py3.3.egg/setuptools/extension.py", line 8, in <module>
File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked
File "/tmp/tmp4uaaq8/setuptools-12.1-py3.3.egg/setuptools/dist.py", line 19, in <module>
File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked
File "/tmp/tmp4uaaq8/setuptools-12.1-py3.3.egg/pkg_resources/__init__.py", line 83, in <module>
AttributeError: 'module' object has no attribute '_vendor'
The command "python bootstrap.py" failed and exited with 1 during .

see: https://travis-ci.org/crate/crash/jobs/50315097

python bootstrap.py downloads setuptools 12.1 but 12.0.5 is already installed, causing a version conflict.

is there a way to use virtualenv without setuptools preinstalled, using the --no-setuptools option when creating it?

right now I added - pip uninstall setuptools -y to the install section in the .travis.yml
that solves the problem, but is only a workaround
https://travis-ci.org/crate/crash/jobs/50320741

[BanzaiMan]

@dstufft What is your opinion on this issue?

[dstufft]

Not installing setuptools is likely to break a fair number of things. I'd be curious if this is a generic problem with buildout-bootstrap.py inside of an environment where setuptools is already installed, or if this is a problem with 12.0.5 in specific.

[tdsmith]

This issue recently manifested itself here: https://github.com/Homebrew/homebrew-python/issues/274

The existence of an old setuptools egg in /Library on the default OS X image led to the issue because the egg .pth magic foiled our attempt to ensure that we were providing a modern setuptools for a dependency using PYTHONPATH.

(Note, for the curious, that the order of sys.path in the debug output in the build in the linked issue is not the same as the order of sys.path in the Python environment where the failure occurs, because the python Homebrew ships has defensive spells against eggs in /Library slinking to the front of sys.path and system python does not.)

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues