Skip to content

pip install and pip search use different version comparisons #368

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
iffy opened this issue Oct 13, 2011 · 2 comments
Closed

pip install and pip search use different version comparisons #368

iffy opened this issue Oct 13, 2011 · 2 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@iffy
Copy link

iffy commented Oct 13, 2011

pip search uses distutils.version classes for version comparisons.
pip install uses pkg_resources.parse_version for version comparisons.

I think they should use the same comparison logic.

I've run into the problem hosting a company-internal project that changed from date-based versions to name-based versions:

v11.10
v11.ape

Assuming pip install used distutils.version sorting, v11.ape is the latest, but pkg_resources disagrees.

$ python
Python 2.6.2 (r262:71600, Jul 21 2010, 16:50:37) 
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.version import LooseVersion
>>> 
>>> raw_versions = ['11.09', '11.ace', '11.10', '11.banana']
>>> versions = map(LooseVersion, raw_versions)
>>> versions.sort()
>>> print versions
[LooseVersion ('11.09'), LooseVersion ('11.10'), LooseVersion ('11.ace'), LooseVersion ('11.banana')]
>>> 
>>> 
>>> from pkg_resources import parse_version
>>> versions = map(parse_version, raw_versions)
>>> versions.sort()
>>> print versions
[('00000011', '*ace', '*final'), ('00000011', '*banana', '*final'), ('00000011', '00000009', '*final'), ('00000011', '00000010', '*final')]
@ogirardot
Copy link
Contributor

This will be fixed by #395

@carljm
Copy link
Contributor

carljm commented Dec 9, 2011

Closing as dupe of #395, thanks for tracking this down @ssaboum

@carljm carljm closed this as completed Dec 9, 2011
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 6, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

No branches or pull requests

3 participants