TypeError: unorderable types: str() < NoneType()

[ghost]

Originally reported by: ionelmc (Bitbucket: ionelmc, GitHub: ionelmc)

---

sudo easy_install-3.3 -U setuptools pip wheel

Searching for setuptools
Reading https://pypi.python.org/simple/setuptools/
Reading http://peak.telecommunity.com/snapshots/
Reading https://pypi.python.org/pypi/setuptools
Traceback (most recent call last):
  File "/usr/local/bin/easy_install-3.3", line 9, in <module>
    load_entry_point('setuptools==2.1', 'console_scripts', 'easy_install-3.3')()
  File "/usr/local/lib/python3.3/dist-packages/setuptools-2.1-py3.3.egg/setuptools/command/easy_install.py", line 1909, in main
  File "/usr/local/lib/python3.3/dist-packages/setuptools-2.1-py3.3.egg/setuptools/command/easy_install.py", line 1896, in with_ei_usage
  File "/usr/local/lib/python3.3/dist-packages/setuptools-2.1-py3.3.egg/setuptools/command/easy_install.py", line 1913, in <lambda>
  File "/usr/lib/python3.3/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.3/distutils/dist.py", line 929, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.3/distutils/dist.py", line 948, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.3/dist-packages/setuptools-2.1-py3.3.egg/setuptools/command/easy_install.py", line 358, in run
  File "/usr/local/lib/python3.3/dist-packages/setuptools-2.1-py3.3.egg/setuptools/command/easy_install.py", line 581, in easy_install
  File "/usr/local/lib/python3.3/dist-packages/setuptools-2.1-py3.3.egg/setuptools/package_index.py", line 580, in fetch_distribution
  File "/usr/local/lib/python3.3/dist-packages/setuptools-2.1-py3.3.egg/setuptools/package_index.py", line 566, in find
  File "/usr/local/lib/python3.3/dist-packages/setuptools-2.1-py3.3.egg/pkg_resources.py", line 770, in __getitem__
    _sort_dists(dists)
  File "/usr/local/lib/python3.3/dist-packages/setuptools-2.1-py3.3.egg/pkg_resources.py", line 2551, in _sort_dists
    tmp.sort()
TypeError: unorderable types: str() < NoneType()

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/137

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

I don't get that error when I run the command in my Python 3.4b2 environment on Windows. I haven't yet tried on another platform. However, given that this code is largely unchanged over the years and that this issue has not been more broadly reported, I suspect there is something unique to your environment that's triggering the error.

That doesn't mean that it's not a bug, but only that it isn't a widespread bug, and because I can't replicate it, I'll need you to provide more detail about the nature of the issue.

Can you confirm that you still have the issue? If so, does the issue persist if you downgrade to an older setuptools (such as 2.0.2)? If the problem persists, perhaps do this for me to help us understand the nature of the failure better:

sudo python3.3 -m pdb `which easy_install-3.3` -U setuptools pip wheel

That will launch pdb (the python debugger) with the easy_install script. It'll break right away so hit c to continue.

I expect it will proceed and then fail with the same traceback as above. If it does, it should leave you at a pdb> prompt. At this point, type print(tmp) and report the results. It should provide more detail about the list that is failing to sort so we can determine which attributes are None and compared to strings.

[ghost]

Original comment by lgautier (Bitbucket: lgautier, GitHub: lgautier):

---

I experienced a similar issue when moving a project from distutils to setuptools when changing in setup.py

from distutils.core import setup

to

from setuptools import setup

The problem disappeared after I created a new virtualenv and try to install in it.

[ghost]

Original comment by david_a_joy (Bitbucket: david_a_joy, GitHub: Unknown):

---

I just experienced this on centos6 with a source built python3.4.1. This was installing setuptools directly from setup.py (after getting the same error with a pip install --upgrade setuptools).

#!shell
$ python3.4 setup.py install
...lots of output
TypeError: unorderable types: NoneType() < str()

Running the debugger as instructed above:

#!shell

TypeError: unorderable types: NoneType() < str()

(Pdb) print(dists)
[matplotlib 1.4.2 (/sw/python3/lib/python3.4/site-packages), matplotlib 1.4.2 (/sw/python3/lib/python3.4/site-packages)]

So matplotlib is somehow in my site-packages twice. That's weird, but probably due to the fact that I upgraded setuptools in the middle of a deployment, then tried to upgrade matplotlib again.

#!shell
$ ls /sw/python3/lib/python3.4/site-packages/ | grep matplotlib
matplotlib
matplotlib-1.4.2.dist-info
matplotlib-1.4.2-py3.4.egg-info
matplotlib-1.4.2-py3.4-nspkg.pth

Removing all the matplotlib related files from site-packages makes setup.py succeed with no errors. If I reinstall matplotlib, now I get this:

#!shell
$ ls /sw/python3/lib/python3.4/site-packages/ | grep matplotlib
matplotlib
matplotlib-1.4.2.dist-info
matplotlib-1.4.2-py3.4-nspkg.pth

So I'm thinking this happens when there are old egg-info files laying around?

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

Oh, that's helpful. Looks like there's egg-info metadata and dist-info metadata co-existing. I might be able to create a repro test from that.

[ghost]

Original comment by arfrever (Bitbucket: arfrever, GitHub: arfrever):

---

See issue #292 for a similar problem.

[ghost]

Original comment by yaniv256 (Bitbucket: yaniv256, GitHub: yaniv256):

---

I think this is related to #264. You can't use sort in python 3 unless you know that it is all the same type. I get this error when doing sudo pip3 install -e . on the ipython git.

[ghost]

Original comment by ionelmc (Bitbucket: ionelmc, GitHub: ionelmc):

---

@jaraco Did you manage to reproduce? I can try to provide you the broken dist-info files if not ...

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

@ionelmc I haven't had a chance to look into it. The dist-info files would be helpful. Even more helpful would be a test in the test suite that captures the failure.

[ghost]

Original comment by craigspry (Bitbucket: craigspry, GitHub: craigspry):

---

I don't know if this helps but this is how I've managed to reproduce this, I've done this on Linux Mint,running under virtual box and on a koding.com free vm. First I installed matplotlib for python2.7 using:
sudo apt-get install python-matplotlib
Then I installed python3 and pip3 using:
sudo apt-get install python3
sudo apt-get install python3-pip
Then I ran:
sudo pip3 install matplotlib

This got me the same result as has been discussed above. On OSX I managed to install matplotlib for python2.7 and python3, but I installed matplotlib for python2.7 so long ago I'm not sure how I installed it, but I suspect I used pip, for python3 I used pip.

[ghost]

Original comment by minrk (Bitbucket: minrk, GitHub: minrk):

---

I've seen this as a result of a mixture of non-setuptools and setuptools installs, where the non-setuptools install of a package has None for platform or py_version, while the setuptools install has both defined as strings, which are not comparable to None on py3. pull request #122 turns None into '' in hashcmp, ensuring that hashcmp always returns a tuple of the same types, and thus always comparable.

[ghost]

Original comment by minrk (Bitbucket: minrk, GitHub: minrk):

---

I can reproduce this with a conda environment by doing a non-setuptools install after a setuptools install, ensuring that both are present:

#!bash
conda create -n test-hash python=3 pip
source activate test-hash
pip install requests
conda install requests
pip install anything # <- fails with str < None

The result is two requests are found, one with py_version='3.4', one with py_version=None.

[ghost]

Original comment by asif_m (Bitbucket: asif_m, GitHub: Unknown):

---

I solved my problem (Win 8.1, Python 3.4.2) with the change suggested here:

https://bitbucket.org/pypa/setuptools/pull-request/122/ensure-py_version-and-platform-are-str-in/diff#chg-pkg_resources/__init__.py

[ghost]

Original comment by lgautier (Bitbucket: lgautier, GitHub: lgautier):

---

Thanks for the note.

[ghost]

Original comment by rgaiacs (Bitbucket: rgaiacs, GitHub: rgaiacs):

---

I have this problem with Python 3.4.3 but not with Python 3.5.0a1+.

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

Issue #350 was marked as a duplicate of this issue.

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

Fixed with c995677d5321. Released as 14.2.