On 2016-07-14 17:23:24 +0100 (+0100), Robin Becker wrote:
not really sure why this is an issue. All of my problems are in virtual environments and I never use the --system-site-packages flag.
I have never used pip to install anything system wide (so far as I know).
Ahh, whoops, after rereading back through some of your earlier messages in the thread I see this is indeed all in the scope of a virtualenv.
Step 0 in after setting up an environment is pip install -U pip setuptools
Of course you are right in that the python is a distro provided one; and also the pip and virtualenv etc etc. [...]
I've noticed in the past that for some reason the system pkg_resources can end up getting used by setuptools (on Debian/Ubuntu it's unvendored and split into a separate python-pkg-resources deb). I haven't had an opportunity to track it down. You might try myenv/bin/python -c 'import sys;print sys.path' and then check the results in order to see which the first one is to provide pkg_resources. Hunting around a bit, this looks similar to https://github.com/pypa/setuptools/issues/497 so see if any of the suggestions mentioned there help at all.
When I run python -mvirtualenv I end up with an environment that has pip and setuptools already. Are you saying I should do
/usr/bin/python -mvirtualenv --no-pip --no-setuptools myenv myenv/bin/python get_pip.py [...]
No, but you might try bootstrapping a newer version of virtualenv into its own virtualenv, like: virtualenv foo foo/bin/pip install -U pip setuptools virtualenv foo/bin/virtualenv myenv Doing that on some systems where I'm forced to start from distro-provided pip/setuptools/virtualenv has worked out consistently well. -- Jeremy Stanley