When pip installing a package that shares a namespace it fails out on 31.0.0 but installs fine on 28.8.0
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.5/site-packages/setuptools/__init__.py", line 10, in <module>
from setuptools.extern.six.moves import filter, filterfalse, map
File "/usr/lib/python3.5/site-packages/setuptools/extern/__init__.py", line 1, in <module>
from pkg_resources.extern import VendorImporter
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3015, in <module>
@_call_aside
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2999, in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3043, in _initialize_master_working_set
for dist in working_set
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3043, in <genexpr>
for dist in working_set
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2573, in activate
declare_namespace(pkg)
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2147, in declare_namespace
_handle_ns(packageName, path_item)
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2087, in _handle_ns
_rebuild_mod_path(path, packageName, module)
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2116, in _rebuild_mod_path
orig_path.sort(key=position_in_sys_path)
AttributeError: '_NamespacePath' object has no attribute 'sort'
From what I can tell, this is a 3.5-only failure.
I can trigger the error just by importing setuptools. However, when I do it a second time, it imports fine. So, if I do something like this, the install succeeds.
try:
from setuptools import setup, find_packages
except AttributeError:
from setuptools import setup, find_packages
I tried adding a test to capture the failure, but the test is passing. So to some extent it's working. Why is the test working but your package not?
@jaraco The bug happens trying to import setuptools/pkg_resources in an environment where a namespace package is installed, but where there is more than one directory in the path of the namespace package (e.g., one package in a "development install" vs. dependencies installed into site-packages).
In @jkbbwr's case above, what would cause zope.__path__ to be an instance of _NamespacePath rather than the plain list that the code in pkg_resources._rebuild_mod_path clearly expects? That class appears only to be instantiated by the stdlib's import machinery under Python 3.5+:
importlib._bootstrap_external._NamespaceLoader.__init__importlib._bootstrap_external.PathFinder.find_spec.As a hackaround, one might add monkeypatch a sort method onto importlib._bootstrap_external._NamespacePath. ;)
I've just pushed another commit, this one in the test_develop module. This test does as you describe, installs one package into a simulated site-packages (myns.pkgA) and another using develop (myns.pkgB). Both packages are importable and pkg_resources can still be imported as well.
what would cause
zope.__path__to be an instance of_NamespacePathrather than the plain list that the code in pkg_resources._rebuild_mod_path clearly expects?
It's almost certainly the fact that the new -nspkg.pth files are using importlib.util.module_from_spec to initialize the module (and thus setting __path__).
I continue to be unable to replicate the error indicated. Here's one such attempt:
$ python -m venv ~/.envs/issue885
$ ~/.envs/issue885/bin/pip install -U setuptools
Collecting setuptools
Using cached setuptools-31.0.0-py2.py3-none-any.whl
Installing collected packages: setuptools
Found existing installation: setuptools 28.8.0
Uninstalling setuptools-28.8.0:
Successfully uninstalled setuptools-28.8.0
Successfully installed setuptools-31.0.0
$ ~/.envs/issue885/bin/pip install -U zope.component
Collecting zope.component
Using cached zope.component-4.3.0.tar.gz
Requirement already up-to-date: setuptools in /Users/jaraco/.envs/issue885/lib/python3.6/site-packages (from zope.component)
Collecting zope.interface>=4.1.0 (from zope.component)
Using cached zope.interface-4.3.2.tar.gz
Collecting zope.event (from zope.component)
Using cached zope.event-4.2.0.tar.gz
Installing collected packages: zope.interface, zope.event, zope.component
Running setup.py install for zope.interface ... done
Running setup.py install for zope.event ... done
Running setup.py install for zope.component ... done
Successfully installed zope.component-4.3.0 zope.event-4.2.0 zope.interface-4.3.2
$ pwd
/Users/jaraco/zope.interface
$ ~/.envs/issue885/bin/pip install -e .
Obtaining file:///Users/jaraco/zope.interface
Requirement already satisfied: setuptools in /Users/jaraco/.envs/issue885/lib/python3.6/site-packages (from zope.interface==4.3.3.dev0)
Installing collected packages: zope.interface
Found existing installation: zope.interface 4.3.2
Uninstalling zope.interface-4.3.2:
Successfully uninstalled zope.interface-4.3.2
Running setup.py develop for zope.interface
Successfully installed zope.interface
$ cd ~
$ ~/.envs/issue885/bin/python
Python 3.6.0rc1 (v3.6.0rc1:29a273eee9a5, Dec 6 2016, 16:24:13)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
>>> import zope.interface
>>> zope.interface.__file__
'/Users/jaraco/zope.interface/src/zope/interface/__init__.py'
>>> zope.__path__
_NamespacePath(['/Users/jaraco/.envs/issue885/lib/python3.6/site-packages/zope', '/Users/jaraco/zope.interface/src/zope'])
What steps do you have to invoke to get a virtual environment that replicates this issue?
This is also occurring consistently over at https://github.com/GoogleCloudPlatform/google-auth-library-python in our lint tox (sample failure).
It'll also occur in other tox environment if you run them twice. The first time tox creates the environment from scratch, but when it tries to re-use an existing environment it 'splodes.
Let me know if I can do anything else to help reproduce/fix this.
Excellent. That does help. I simply checked out GoogleCloudPlatform/google-auth-library-python and ran tox -e lint and that replicated the failure. I should be able to distill the issue from there. Thanks.
Awesome. 👍
I just hit this same problem. I can craft a reproducer if you need it. I see it when running tox on a py35 environment with flufl.i18n, which uses flufl.testing, both of which are namespace packages. I need to commit and push a fix to the latter for you to reproduce it. Let me know if you need it, but it would be really great to get a quick fix released for this bug.
FWIW, it affects Python 3.6 also; I can't test 3.4.
Working with the google-auth library, I find that if I set usedevelop = True in the tox settings, the issue doesn't occur. This behavior indicates to me that the issue lies in part with a package which is duplicately installed. In any case, I was able to use it to create a test case that captures the error.
@jaraco That's interesting because I have usedevelop=True and it happens for me. But at least you ahve a reproducer. :)
usedevelop probably won't work except in that specific case because
google-auth uses namespace packages.
On Tue, Dec 13, 2016, 6:01 PM Jason R. Coombs notifications@github.com
wrote:
Working with the google-auth library, I find that if I set usedevelop =
True in the tox settings, the issue doesn't occur. This behavior
indicates to me that the issue lies in part with a package which is
duplicately installed. In any case, I was able to use it to create a test
case that captures the error.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pypa/setuptools/issues/885#issuecomment-266921037,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPUcwf9-z3hwrnuPlbbGLeyiea38dH-ks5rH04MgaJpZM4LKdo7
.
@jonparrott: The whole point of v31.0.0 and the fix for #250 is that 'develop' and namespace packages should work well together now, so I hope you can drop that assumption soon.
@warsaw: The fix is in place. Can you update setuptools in your test environment to git+https://github.com/pypa/setuptools@3943cf4 and see if that addresses the manifestation you encountered?
Well hell. The fix works for Python 3.6 but not for Python 3.5. Thanks to Travis for catching that.
Okay. Yet another version to test against, this one passes on Python 3.5. git+https://github.com/pypa/setuptools@7c0c39ef. I'm not happy with the fix, but it passes the tests.
@jaraco I get another bug now:
Traceback (most recent call last):
File "setup.py", line 2, in <module>
from setuptools import setup, find_packages
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/setuptools/__init__.py", line 10, in <module>
from setuptools.extern.six.moves import filter, filterfalse, map
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/setuptools/extern/__init__.py", line 1, in <module>
from pkg_resources.extern import VendorImporter
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3015, in <module>
@_call_aside
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2999, in _call_aside
f(*args, **kwargs)
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3043, in _initialize_master_working_set
for dist in working_set
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3043, in <genexpr>
for dist in working_set
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2573, in activate
declare_namespace(pkg)
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2147, in declare_namespace
_handle_ns(packageName, path_item)
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2087, in _handle_ns
_rebuild_mod_path(path, packageName, module)
File "/home/barry/projects/flufl/i18n/.tox/py35-nocov/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2116, in _rebuild_mod_path
orig_path[:] = sorted(orig_path, key=position_in_sys_path)
TypeError: '_NamespacePath' object does not support item assignment
@warsaw: For some reason, I didn't get notified of your message. My latest commit should have addressed the item assignment bug (by simply bypassing the sort behavior). I've released the fix as v31.0.1. Please let me know how that works for you.
@jaraco I can confirm that 31.0.1 fixes the Python 3.5 test failure for google-cloud-python.
@jaraco Something seems very messed up with my tox environments, but if I wrestle it enough to install the latest pypi version, it does seem to work well now. Thanks!
Thanks, @jaraco!
I'm having this issue when trying to pip install --upgrade git+ssh://[email protected]/some/package.git#egg=name when the package is already installed (trying to upgrade).
pip list shows setuptools (32.1.2)
Should I file a new issue?
@villasv: You probably have an old version of pkg_resources lingering in your environment. First check that import pkg_resources; print(pkg_resources.__file__) doesn't point to a lingering old version. If that's not the issue, use pip to uninstall and reinstall setuptools. If you still have the issue, do please file a new issue with steps to replicate.
Broken with: 34.1.1
I have got the same error with pip form the distribution python3-pip packages from ubuntu 16.10
If I execute import pkg_resources; print(pkg_resources.__file__) in the shell the first time it throws the error from op, the second time it works.
This issue is fixed in setuptools, but it's still broken in pip.
As this issue is still affecting me in pip, I've continued to investigate. I was able to replicate the error simply by installing a namespace package, having that namespace package also minimally present on sys.path (in .) and to import pkg_resources, e.g.:
pip install jaraco.itertools
mkdir jaraco
echo '__import__("pkg_resources").declare_namespace(__name__)' > jaraco/__init__.py
python -c "import pkg_resources"
Note that the jaraco directory need not have the declare_namespace
When initializing the master working set, pkg_resources activates the jaraco.itertools distribution, which causes the declare_namespace('jaraco'), which fails on the _handle_ns('jaraco', '').
The issue only occurs when the installed namespace package was built with Setuptools 31.0.0 or later (with the newest -nspkg.pth file technique). I don't encounter the issue if installing an older wheel that doesn't have that newer technique.
Tracing the code, the reason the aberrant behavior only exhibits when the -nspkg.pth was built on Setuptools 31 is because the old -nspkg.pth behavior would only add modules to sys.modules for older Pythons and would rely on pep-420 otherwise.
As a result, in Distribution.activate, the call to declare_namespace would not be reached.
With a Setuptools 31 -nspkg.pth file, declare_namespace gets called, which invokes _handle_ns on every path in sys.path, including ''.
@tseaver setuptools 31.0.1 did not work for me. What version of pip are you on? Does anyone know a combination of setuptools, pip, and google-cloud (recent version) that works reliably?
@esafak Try updating both setuptools and pip in a new virtualenv:
$ python3 -m venv /tmp/gcloud
$ /tmp/pypa-885/bin/pip3 install -U setuptools pip
...
$ /tmp/pypa-885/bin/pip3 install google-cloud
...
And then:
>>> from google.cloud.datastore import Client
Also ran into the issue on readthedocs with python 3.5: https://readthedocs.org/projects/luma-led-matrix/builds/5081789/ but it's possible to use python 2.7 there which presumably doesn't have this issue, so I think I'll take the easy way out.
This bug has popped up again over here in this ticket https://github.com/opencivicdata/python-opencivicdata-django/issues/80
The user reports:
Python 3.5.2
setuptools 34.3.2
I can repro this issue very simply,
python 3.6, setuptools 34.3.3, virtualenv 15.1.0, windows10, mingw64 git bash shell
virtualenv runtime
source runtime/Scripts/active
pip install twisted
pip install autobahn
this installs twisted 17.1.0, and then fails trying to install autobahn
I was having the similar errors while trying to install google cloud sdk while building a docker image with python 3.5.2, pip 9.0.1, setuptools 34.3.2 (which is based off official python:3.5-slim docker image). Logs is here.
Force pip upgrade to setuptools 34.3.3 made it work, one liner workaround:
RUN pip install --upgrade setuptools==34.3.3 && pip install google-cloud
And it appears that pypi.python.org has already been updated to offer setuptools 34.3.3 as the latest version.
I can repro this issue very simply,
Oy. That's on Windows using an open-source compiler and a couple of different other packages. I did try the same on MacOS with Python 3.6.1 but couldn't replicate the issue, so something about Windows or mingw64 is apparently implicated. Plus, we know that pip still bundles this bug, so that's probably the issue.
Thanks for trying my setup out!
I am not seeing the issue with my main install of python 3.6 - only inside the virtualenv. Does that make sense with your observation that 'pip still bundles this bug?'
It's even more fragile than I thought - after the first 'pip install twisted', I can't even do 'pip list' - I get the same error.
File "c:\akit\runtime\lib\site-packages\pip\_vendor\pkg_resources\__init__.py", line 2121, in _rebuild_mod_path
orig_path.sort(key=position_in_sys_path)
AttributeError: '_NamespacePath' object has no attribute 'sort'
Setuptools is listed as version 34.3.3 inside the virtualenv lib/site-packages.
I hope this info is helpful - let me know if there's anything I can test which might confirm/deny?
BTW, one of Twisted's dependencies is zope.interface, which I saw listed as a problem package in one of these referenced bugs, I think?
yep, zope.interface is also a namespace package where we experience problems with.
Just look at the trace back you get. If the error is occurring in a file found in pip, then the issue doesn't lie with Setuptools, and it won't matter which version of Setuptools you have installed.
Yes, pip list has a traceback totally within pip. Thank you for clarifying it for me.
I see the pip bug https://github.com/pypa/pip/issues/4216 is still open and they haven't quite managed to get a fix out yet.
It worked for me just run
conda config --set ssl_verify False
if you are facing this issue while creating an environment on anaconda 3.6.1
I modified the function _rebuild_mod_path of the file(.../site-packages/pip/_vendor/pkg_resources/__init__.py), which worked:
````
orig_path_t = list(orig_path) # added
orig_path_t.sort(key=position_in_sys_path) # added
module.__path__[:] = [_normalize_cached(p) for p in orig_path_t] # added
An even better fix would be to use sorted, e.g.:
module.__path__[:] = [_normalize_cached(p) for p in sorted(orig_path)]
Fixed this by upgrading my setuptools
pip install --upgrade setuptools
I've still this bug on the latest version (36.0.1) whereas it works fine on the previous release on pypi (35.0.2)
Same problem here. Ubuntu 16.04, python 3.5 inside a virtualenv, setuptools 36.0.1 gives this error while 35.0.2 works fine.
You probably aren't getting this with Setuptools, but with pkg_resources vendored in pip. If you are getting the error in setuptools, please file a new ticket and include the traceback and other environmental conditions that created the bug. Otherwise, look for the pip link above and follow that.
Also fixed this issue with an update of setup tools by first pip uninstalling setup tools and reinstalling
fixed by
pip install --upgrade setuptools
pip install --upgrade pip
hmm... how might one follow @frankyaorenjie 's solution just above if attempting to use pip to upgrade (or uninstall) setuptools also throws that error?
hmm... how might one follow @frankyaorenjie 's solution just above if attempting to use pip to upgrade (or uninstall) setuptools also throws that error?
This helped me with the issue
easy_install pip
easy_install setuptools
It could also be the virtualenv that's old. Switching from 15.0.1 to 15.1.0 fixed this for me.
Same problem on Mac with python 3.6:
File "/Users/test/anaconda3/lib/python3.6/site-packages/setuptools-27.2.0-py3.6.egg/pkg_resources/__init__.py", line 2087, in _rebuild_mod_path
AttributeError: '_NamespacePath' object has no attribute 'sort'
tried:
pip install --upgrade setuptools
pip install --upgrade pip
and many other solutions but failed:(
This issue was fixed in 31.0.1. The error message you reported shows that you have Setuptools 27.2.0. If you did upgrade setuptools successfully, the error message should go away or may mutate to the pip bug (if you see pip in the path to pkg_resources, the issue lies with pip, which still is the case for 9.0.1).
It's also possible that the issue will persist if the namespace packages being installed aren't properly packaged (every package in the namespace uses a consistent technique) or possibly if some were built with older versions of setuptools (and thus have an older -nspkg.pth file), you might still encounter this issue.
So do please include the error message you're getting after upgrading pip and setuptools. Also, uninstall and reinstall your namespace packages. If you're still having issues, and 'pip' doesn't appear in the traceback when the error occurs, give us a report on the -nspkg.pth files in your site-packages with something like:
for pth in $(ls /Users/test/anaconda3/lib/python3.6/site-packages/*-nspkg.pth); do
echo $pth
cat $pth
done
I was having the same exact issue with both python3.5 and python3.6 on ubuntu 16.04. I tried installing setuptools from sorc git master . but the get-pip was still failing with the same error :
AttributeError: '_NamespacePath' object has no attribute 'sort'
I had to manually remove the *-nspkg.pth files from my site-ackages directory in order to have pip back working. The package involved were: matplotlib, protobuf, virtualenvwrapper.
How is this still a problem after over a year later.
I just encountered the same problem. I've tried all the solutions given on this page, but the problem still persists. This is what I see:
Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/local/lib/python3.5/dist-packages/virtualenvwrapper/hook_loader.py", line 16, in <module>
from stevedore import ExtensionManager
File "/usr/local/lib/python3.5/dist-packages/stevedore/__init__.py", line 11, in <module>
from .extension import ExtensionManager
File "/usr/local/lib/python3.5/dist-packages/stevedore/extension.py", line 17, in <module>
import pkg_resources
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2927, in <module>
@_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2913, in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2952, in _initialize_master_working_set
add_activation_listener(lambda dist: dist.activate())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 956, in subscribe
callback(dist)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2952, in <lambda>
add_activation_listener(lambda dist: dist.activate())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2515, in activate
declare_namespace(pkg)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2097, in declare_namespace
_handle_ns(packageName, path_item)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2047, in _handle_ns
_rebuild_mod_path(path, packageName, module)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2066, in _rebuild_mod_path
orig_path.sort(key=position_in_sys_path)
AttributeError: '_NamespacePath' object has no attribute 'sort'
Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/local/lib/python3.5/dist-packages/virtualenvwrapper/hook_loader.py", line 16, in <module>
from stevedore import ExtensionManager
File "/usr/local/lib/python3.5/dist-packages/stevedore/__init__.py", line 11, in <module>
from .extension import ExtensionManager
File "/usr/local/lib/python3.5/dist-packages/stevedore/extension.py", line 17, in <module>
import pkg_resources
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2927, in <module>
@_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2913, in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2952, in _initialize_master_working_set
add_activation_listener(lambda dist: dist.activate())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 956, in subscribe
callback(dist)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2952, in <lambda>
add_activation_listener(lambda dist: dist.activate())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2515, in activate
declare_namespace(pkg)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2097, in declare_namespace
_handle_ns(packageName, path_item)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2047, in _handle_ns
_rebuild_mod_path(path, packageName, module)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2066, in _rebuild_mod_path
orig_path.sort(key=position_in_sys_path)
AttributeError: '_NamespacePath' object has no attribute 'sort'
You probably have an older setuptools installed to /usr/lib/python3/dist-packages. You'll want to remove all traces of setuptools and pkg_resources from there and then reinstall a late version of setuptools with pip.
Same issue. I am using python3.5
I'm locking the discussion on this issue. The code was changed such that this error won't occur on setuptools 31.0.1 and later. If it's happening, it's because you have an old setuptools somewhere (possibly vendored in pip or maybe latent from another cause). There's nothing more this project can do about it at this time.
I've unlocked the conversation here. Others have pointed out that there are other ways users can encounter this issue, so might as well make this issue a wiki about the ways people can encounter the issue and how they worked around it.
It is still a problem on Ubuntu 16.04. It is easy to simulate it with
apt install python3-pip
apt install glances
then trying to run glances gives above error. After reading all these long threads it is not clear how this has to be fixed. I also noticed apt, pip and pip3 all install packages into different locations. So far I have:
/usr/lib/python/python2.7/
/usr/lib/python/python3/
/usr/lib/python/python3.5/
/usr/local/lib/python2.7/
/usr/local/lib/python3.5/
Why is there such a mess after one is using standard routines to install packages (either apt or pip) ?!
I'm unable to replicate your findings:
$ echo "from ubuntu:xenial\nrun apt update\nrun apt install -y python3-pip\nrun apt install -y glances\nRUN glances -V" | docker build -
Sending build context to Docker daemon 2.048kB
Step 1/5 : from ubuntu:xenial
---> c9d990395902
Step 2/5 : run apt update
---> Using cache
---> 0dd53993e06c
Step 3/5 : run apt install -y python3-pip
---> Using cache
---> ead4e3396444
Step 4/5 : run apt install -y glances
---> Using cache
---> 705a7a53d0ee
Step 5/5 : RUN glances -V
---> Running in 1c737e6faf2d
Glances v2.3 with psutil v3.4.2
Removing intermediate container 1c737e6faf2d
---> d46ab038485d
Successfully built d46ab038485d
(also running simply glances in an interactive terminal works).
Why is there such a mess?
Setuptools fixed this in 31.0.1. Pip incorporated the fix in 10.0.0b1. venv still pulls in older setuptools versions. Downstream package managers may not have pulled in these fixes.
Maybe this another kind of this issue:
$ pip3 install --upgrade setuptools
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pip/_vendor/__init__.py", line 33, in vendored
__import__(vendored_name, globals(), locals(), level=0)
ImportError: No module named 'pip._vendor.pkg_resources'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/pip3", line 9, in <module>
from pip import main
File "/usr/lib/python3/dist-packages/pip/__init__.py", line 13, in <module>
from pip.exceptions import InstallationError, CommandError, PipError
File "/usr/lib/python3/dist-packages/pip/exceptions.py", line 6, in <module>
from pip._vendor.six import iteritems
File "/usr/lib/python3/dist-packages/pip/_vendor/__init__.py", line 75, in <module>
vendored("pkg_resources")
File "/usr/lib/python3/dist-packages/pip/_vendor/__init__.py", line 36, in vendored
__import__(modulename, globals(), locals(), level=0)
File "<frozen importlib._bootstrap>", line 969, in _find_and_load
File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
File "/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py", line 2927, in <module>
File "/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py", line 2913, in _call_aside
File "/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py", line 2952, in _initialize_master_working_set
File "/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py", line 956, in subscribe
File "/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py", line 2952, in <lambda>
File "/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py", line 2515, in activate
File "/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py", line 2097, in declare_namespace
File "/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py", line 2047, in _handle_ns
File "/usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl/pkg_resources/__init__.py", line 2066, in _rebuild_mod_path
AttributeError: '_NamespacePath' object has no attribute 'sort'
Upgrade doesn't help but uninstall setuptools then reinstall fixed it for me.
I am using Ubuntu 16.04.03 in virtualenv.
What doesn't work:
pip3 install --upgrade setuptools
Requirement already up-to-date: setuptools in ./lib/python3.5/site-packages (39.1.0)
pip install 'package'
.............
AttributeError: '_NamespacePath' object has no attribute 'sort'
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-install-fukuqph1/googleapis-common-protos/
What works:
pip uninstall setuptools
Uninstalling setuptools-39.1.0:
Would remove:
~/bin/easy_install
~/bin/easy_install-3.5
~/bin/easy_install-3.6
~/lib/python3.5/site-packages/easy_install.py
~/lib/python3.5/site-packages/pkg_resources/*
~/lib/python3.5/site-packages/setuptools-39.1.0.dist-info/*
~/lib/python3.5/site-packages/setuptools/*
Proceed (y/n)? y
Successfully uninstalled setuptools-39.1.0
pip install setuptools
Requirement already satisfied: setuptools in ./lib/python3.5/site-packages/setuptools-39.1.0-py3.5.egg (39.1.0
pip install 'package'
.....
Successfully installed cachecontrol-0.12.4 cachetools-2.0.1....
Hope it helps someone else!
Thanks.
Still experiencing this issue, fresh virtualenv and setuptools reinstallation did not help.
@Belval you have a fix for this ? setuptools -39.2.0
I was running into the same issue, when I went to recreate the virtualenv the version of python I was using, 3.5 but it's irrelevant, it was no longer on my system at all! after recreating the virtualenv with a version of python that exists, it works.
Hi, is there a fix/workaround for this? I am getting the "sort" error even when I try pip3 --version, I also can't uninstall setuptools and/or update it (as some of you suggested).
I am using a mac High Sierra.
Try this workaround:
https://stackoverflow.com/questions/47955397/pip3-error-namespacepath-object-has-no-attribute-sort
Edit line #2121~2122 of this file:
"sudo vim /usr/local/lib/python3.5/dist-packages/pip/_vendor/pkg_resources/__init__.py"
#orig_path.sort(key=position_in_sys_path)
#module.__path__[:] = [_normalize_cached(p) for p in orig_path]
orig_path_t = list(orig_path)
orig_path_t.sort(key=position_in_sys_path)
module.__path__[:] = [_normalize_cached(p) for p in orig_path_t]
@lechatthecat <3 thank you very much it worked
I had the same problem using poetry.
Running
poetry run pip install --upgrade pip setuptools
instead of
pip install --upgrade pip setuptools
fixed the issue.
Most helpful comment
I modified the function _rebuild_mod_path of the file(
.../site-packages/pip/_vendor/pkg_resources/__init__.py), which worked:````
orig_path_t = list(orig_path) # added
orig_path.sort(key=position_in_sys_path) # commented
orig_path_t.sort(key=position_in_sys_path) # added
module.__path__[:] = [_normalize_cached(p) for p in orig_path] # commented
module.__path__[:] = [_normalize_cached(p) for p in orig_path_t] # added