Changes/Update python-packaging to version 22 plus

Update python-packaging to version >= 22

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Update to a new upstream release of python-packaging contains a breaking change. Since version 22+ upstream removed support for LegacySpecifier and LegacyVersion some packages will break. This is a breaking change and projects are encouraged to use versions adherent to PEP 440.

Note: Currently, we plan to update to 23.0, but this can be updated even further. The change proposal explicitly mentions version 22+ because that version removed support for LegacyVersions and legacy version specifiers.

Owner

• Name: Tomáš Hrnčiar, Miro Hrončok
• Email: thrnciar@redhat.com, mhroncok@redhat.com

Current status

• Targeted release: Fedora Linux 38
• Last updated: 2023-01-25
• devel thread
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

>>> # before 22.0
>>> packaging.version.parse("This is a completely random string")
<LegacyVersion('This is a completely random string')>

>>> # after 22.0
>>> packaging.version.parse("This is a completely random string")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[...]/.venv/lib/python3.10/site-packages/packaging/version.py", line 52, in parse
    return Version(version)
  File "[...]/.venv/lib/python3.10/site-packages/packaging/version.py", line 197, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: 'This is a completely random string'

This "feature" has been deprecated for nearly two years now.

PyPI has not permitted uploading packages with invalid versions for even more years. The latest versions of pip should be rejecting/erroring out on wheels with such versions as well. The stricter metadata validation helps pip's dependency resolver's logic, along with helping the broader ecology avoid needing to deal with outside-of-standard tooling/behaviours.

Possible failures caused by upgraded python-packaging:

• pinned version of python-packaging
  • cekit - https://bugzilla.redhat.com/show_bug.cgi?id=2162433
  • python-limits - https://src.fedoraproject.org/rpms/python-limits/pull-request/5

• tests containing unsupported versions need to be adjusted
  • copr-backend - https://bugzilla.redhat.com/show_bug.cgi?id=2162436

• some packages provide incompatible versions and python-rpm-generators are unable to parse them. See PRs links below for inspiration on how to fix them.
  • pcs
  • pyodbc - https://src.fedoraproject.org/rpms/pyodbc/pull-request/4
  • python-btchip
  • python-dipy
  • python-dropbox
  • python-haversion - https://src.fedoraproject.org/rpms/python-haversion/pull-request/1
  • python-lacrosse - https://src.fedoraproject.org/rpms/python-lacrosse/pull-request/1
  • python-pdir2 - the sed in %prep needs to be adjusted not to create invalid >=4.2.* requirements
  • python-pvc
  • python-pytest-httpx

See also https://discuss.python.org/t/22782/19 for the exact errors of most of the listed packages.

• other
  • python-httplib2 - uses pyparsing in tests but does not BuildRequire it directly - https://src.fedoraproject.org/rpms/python-httplib2/pull-request/9
  • obs-service-set_version - tests convert LegacyVersions to RPM syntax and the result is different now (not sure?)

• unknown
  • python-google-cloud-bigquery - package does not build in rawhide

How to deal with failures in Python RPM dependency generators

packaging is used in the Python RPM dependency generators (for python3dist() and python3.11dist() Provides, Requires and BuildRequires).

When the packaged software has now invalid versions or comparators, you might need to fix the package.

Example problem:

packaging.version.InvalidVersion: Invalid version: 'main'

See if the version of the Python package isn't failing to be determined automatically and provide the missing information, see https://src.fedoraproject.org/rpms/python-haversion/pull-request/1 or https://src.fedoraproject.org/rpms/python-lacrosse/pull-request/1 and https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_version_warning

Example problem:

 packaging.requirements.InvalidRequirement: Expected end or semicolon (after version specifier)
    typing-extensions>=4.2.*
                    \~\~\~\~\~^

(Backslashes added to the example as a naïve attempt to escape the dashes form this wiki, ignore them).

Adjust the requirement not to use .* in versions when <, <=, >, or >= is used, see https://discuss.python.org/t/22782

Feedback

We are aware that we missed the Change proposal submission deadline, originally we planned to ship this as a regular package update. While doing an impact check we identified ~20 affected packages and we decided to write this Change proposal for better transparency. We believe there is enough time to complete this Change in time for the Completion deadline. We are prepared to postpone this Change to Fedora 39 if FESCo decides so.

Benefit to Fedora

Packaging 22+ contains a handwritten parser for parsing requirements and markers. Thanks to this, packaging has dropped a runtime dependency on pyparsing and from now on is not depending on any package on runtime. This will simplify bootstrapping of the next Python.

Scope

• Proposal owners: update python-packaging to 23.x.x, provide help

• Other developers: report problems to the upstream and backport patch to the affected packages. The impact can be tested using COPR repository where Packaging 23+ has been built.

• Release engineering: N/A (not needed for this Change)

• Policies and guidelines: N/A (not needed for this Change)

• Trademark approval: N/A (not needed for this Change)

• Alignment with Objectives:

How To Test

1. Find the package you want to fix in this COPR repository and check the build logs to determine the failure cause.
2. Patch package so Provides() provides correct version.
3. When patching the package, you can test it using the same copr repository where the latest version of python-packaging has been built.

User Experience

Regular distro users shouldn't notice any change in python-packaging behaviour, except for packages that use LegacyVersion or LegacySpecifier. Such packages will fail with packaging.version.InvalidVersion: Invalid version: 'This is a completely random string' and should be fixed by their maintainers.

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) revert the update and bump epoch
• Contingency deadline: beta freeze
• Blocks release? No

Documentation

https://github.com/pypa/packaging/blob/main/CHANGELOG.rst