Setuptools: _NamespacePath object has no attribute sort (31.0.0)

Created on 12 Dec 2016  ·  73Comments  ·  Source: pypa/setuptools

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'

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

All 73 comments

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 _NamespacePath rather 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.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

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.

Was this page helpful?
0 / 5 - 0 ratings