Stefano, thanks, that does feel much closer to a test case that models a
real-world scenario.
The doubt I still have is, if you're pulling something as fundamental as
setuptools from pip, why are you using virtualenv --system-site-packages
at all? Is this because it's embedded in third-party code that's hard
for the user to change?
This fails:
$ sudo apt install python3-virtualenv python3-distro-info
$ virtualenv --system-site-packages foo
$ foo/bin/python -m pip install -U setuptools
$ foo/bin/python -c "import pkg_resources; pkg_resources.require('distro-info')"
But this succeeds:
$ sudo apt install python3-virtualenv python3-distro-info
$ virtualenv --system-site-packages foo
$ foo/bin/python -m pip install -U setuptools
$ foo/bin/python -c "import pkg_resources; pkg_resources.require('filelock')"
as does this:
$ sudo apt install python3-virtualenv python3-distro-info
$ virtualenv --system-site-packages foo
$ foo/bin/python -m pip install -U setuptools distro-info
$ foo/bin/python -c "import pkg_resources; pkg_resources.require('distro-info')"
It's only when trying to use a setuptools newer than the one in the
distro, with distro versions of specific python modules, that I can
reproduce a failure. So, uh, why do that?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gpgme1.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1991606
Title:
Invalid PEP440 package version breaking setuptools >= 66
Status in devscripts package in Ubuntu:
Fix Released
Status in distro-info package in Ubuntu:
Fix Released
Status in drslib package in Ubuntu:
New
Status in duecredit package in Ubuntu:
Fix Released
Status in gpgme1.0 package in Ubuntu:
Fix Released
Status in python-debian package in Ubuntu:
Fix Released
Status in reportbug package in Ubuntu:
Fix Released
Status in ubuntu-dev-tools package in Ubuntu:
Fix Released
Status in update-manager package in Ubuntu:
Fix Released
Status in devscripts source package in Bionic:
New
Status in distro-info source package in Bionic:
New
Status in drslib source package in Bionic:
Invalid
Status in duecredit source package in Bionic:
New
Status in gpgme1.0 source package in Bionic:
New
Status in python-debian source package in Bionic:
Invalid
Status in reportbug source package in Bionic:
New
Status in ubuntu-dev-tools source package in Bionic:
New
Status in update-manager source package in Bionic:
New
Status in devscripts source package in Focal:
New
Status in distro-info source package in Focal:
New
Status in drslib source package in Focal:
New
Status in duecredit source package in Focal:
New
Status in gpgme1.0 source package in Focal:
New
Status in python-debian source package in Focal:
New
Status in reportbug source package in Focal:
New
Status in ubuntu-dev-tools source package in Focal:
New
Status in update-manager source package in Focal:
New
Status in devscripts source package in Jammy:
New
Status in distro-info source package in Jammy:
New
Status in drslib source package in Jammy:
New
Status in duecredit source package in Jammy:
New
Status in gpgme1.0 source package in Jammy:
New
Status in python-debian source package in Jammy:
New
Status in reportbug source package in Jammy:
New
Status in ubuntu-dev-tools source package in Jammy:
Invalid
Status in update-manager source package in Jammy:
New
Status in devscripts source package in Kinetic:
New
Status in distro-info source package in Kinetic:
Fix Released
Status in drslib source package in Kinetic:
New
Status in duecredit source package in Kinetic:
New
Status in gpgme1.0 source package in Kinetic:
Fix Released
Status in python-debian source package in Kinetic:
Incomplete
Status in reportbug source package in Kinetic:
New
Status in ubuntu-dev-tools source package in Kinetic:
Invalid
Status in update-manager source package in Kinetic:
New
Bug description:
[ Impact ]
With setuptools 66, the versions of all packages visible in the Python
environment *must* obey PEP440 <https://peps.python.org/pep-0440/>.
Otherwise, attempts to use pip to install a package with a setup.py-
based build system, or other attempts to use the `pkg-resources`
module, can produce errors like this:
File
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
line 844, in _resolve_dist
env = Environment(self.entries)
File
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
line 1044, in __init__
self.scan(search_path)
File
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
line 1077, in scan
self.add(dist)
File
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
line 1096, in add
dists.sort(key=operator.attrgetter('hashcmp'), reverse=True)
File
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
line 2631, in hashcmp
self.parsed_version,
File
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/__init__.py",
line 2678, in parsed_version
self._parsed_version = parse_version(self.version)
File
"/builds/databiosphere/toil/venv/lib/python3.9/site-packages/pkg_resources/_vendor/packaging/version.py",
line 266, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
pkg_resources.extern.packaging.version.InvalidVersion: Invalid version:
'0.23ubuntu1'
The official opinion of the setuptools maintainers seems to be that
version strings of this form haven't *really* been allowed since about
2014, and distributions need to change their package version naming
scheme for Python packages they install, so that the resulting version
strings obey PEP440. See for example
<https://github.com/pypa/setuptools/issues/3772#issuecomment-1384342813>.
suffix 1build1 is invalid.
Some python building tools, that verifies if version strings are
compatible with PEP440, are failing.
Example: python poetry: Invalid PEP 440 version: '1.1build1'
[ Test Plan ]
1. Install the affected package and pip plus python3-dev, gcc, libfuzzy-dev:
```
sudo apt update
sudo apt install python3-dev python3-pip python3-distro-info python3-debian
libfuzzy-dev gcc -y
```
2. Install setuptools 67.5 **as normal user** using pip:
```
python3 -m pip install setuptools==67.5.0
```
3. Then try to install ssdeep with pip using that setuptools version:
```
python3 -m pip install ssdeep
```
The installation should succeed with the fixed package, but it will
fail with InvalidVersion with the affected package versions installed.
Commands for Benjamin's local testing with schroot:
```
schroot-wrapper -p
python3-dev,python3-pip,python3-distro-info,python3-debian,libfuzzy-dev,gcc -c
$distro
python3 -m pip install setuptools==67.5.0
python3 -m pip install ssdeep
```
[ Where problems could occur ]
The fix touches only setup.py which is only used for installing the
package. So there should be no effect on the installed package (except
for exposing a different version). But there could be indirect effects
(hidden bugs that trigger on package upgrade, etc).
[ Other Info ]
The related upstream bug report is
https://github.com/pypa/setuptools/issues/3772. As of 2023-04-25 it
has 85 comments and 108 thumbs ups.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/devscripts/+bug/1991606/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
