Skip to content
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

Avoid using LegacyVersion from packaging #2478

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 2 additions & 0 deletions changelog.d/2478.breaking.rst
@@ -0,0 +1,2 @@
Drop support for non PEP440-compliant versions in packages when discovering them from the file system.
-- by :user:`yan12125`
39 changes: 37 additions & 2 deletions pkg_resources/__init__.py
Expand Up @@ -2003,25 +2003,60 @@ def find_nothing(importer, path_item, only=False):
def _by_version_descending(names):
"""
Given a list of filenames, return them in descending order
by version number.
by version number. Non-PEP440 versions are transformed to
lower cases and then compared alphabetically.

>>> names = 'bar', 'foo', 'Python-2.7.10.egg', 'Python-2.7.2.egg'
>>> _by_version_descending(names)
['Python-2.7.10.egg', 'Python-2.7.2.egg', 'foo', 'bar']
>>> names = 'foo-1.3_04.egg', 'foo-1.3.egg'
>>> _by_version_descending(names)
['foo-1.3.egg', 'foo-1.3_04.egg']
>>> names = 'Setuptools-1.2.3b1.egg', 'Setuptools-1.2.3.egg'
>>> _by_version_descending(names)
['Setuptools-1.2.3.egg', 'Setuptools-1.2.3b1.egg']
>>> names = 'Setuptools-1.2.3b1.egg', 'Setuptools-1.2.3.post1.egg'
>>> _by_version_descending(names)
['Setuptools-1.2.3.post1.egg', 'Setuptools-1.2.3b1.egg']
"""

class _NonVersion:
def __init__(self, value):
# Per PEP 440, version strings are compared in a
# case-insensitive manner. Do the same for
# non-version strings.
self._key = value.lower()

def __lt__(self, other):
if isinstance(other, packaging.version.Version):
# mimic packaging's behavior - considering non-PEP440
# versions smaller than PEP440 ones
return True
elif not isinstance(other, _NonVersion):
return self._key < str(other).lower()

return self._key < other._key

def __eq__(self, other):
if not isinstance(other, _NonVersion):
return NotImplemented

return self._key == other._key

def _by_version(name):
"""
Parse each component of the filename
"""
name, ext = os.path.splitext(name)
parts = itertools.chain(name.split('-'), [ext])
return [packaging.version.parse(part) for part in parts]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect parse is used here because it's important to support non-conformant versions (e.g. 1.3_04). I don't know if there are any systems still relying on these legacy versions, but I would not be surprised if there are. At the very least, I'd consider this a 'change' if not 'breaking'.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks this is indeed a breaking change. I changed the category in the latest version of the patch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This now looks to me like we're getting dangerously close to re-implementing LegacyVersion as _NonVersion. It seems to me if packaging is removing support for the Legacy Version, then probably Setuptools should do so too. Here's what I'd like to happen:

  • in the Packaging project (or possibly on another forum like packaging-problems or distutils-sig), discuss the deprecation and removal of LegacyVersion and what they intend to happen in cases where packages still use those versions.
  • Follow the spirit of that change. For example, if they're just testing the waters to see who complains about the deprecation, we should complain and explain this use case that's broken by the change. If they have a plan to wean users off of LegacyVersions by dropping support for them, then we should honor that intent and wean our users off of them as well.

I don't want setuptools to be the dumping ground for legacy behavior. If users want that behavior but the PyPA wishes to dissuade that behavior, Setuptools would like to honor that intent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left pypa/packaging#368 (comment) to inquire about the intentions for packaging in the deprecation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks very much for explanations. Sounds like more discussions are needed before doing code changes. I'll mark this PR as draft.


def parse_version_ignore_invalid(version):
try:
return packaging.version.Version(version)
except packaging.version.InvalidVersion:
return _NonVersion(version)

return [parse_version_ignore_invalid(part) for part in parts]

return sorted(names, key=_by_version, reverse=True)

Expand Down