PEP440 compliance and setuptools >=66.0.0, installation failure
aaronchongth opened this issue · 0 comments
aaronchongth commented
Bug report
Required information:
- Operating system and version: Ubuntu 22.04
- OpenRMF installation type: binary
- OpenRMF version or commit hash: 22.09
- ROS distribution and version: humble
- ROS installation type: binary
- Package or library, if applicable: rmf-web
Description of the bug
Due to breaking changes to setuptools
at v66.0.0
, https://github.com/pypa/setuptools/blob/main/CHANGES.rst#v6600, which requires PEP440 compliant versioning in all packages, the python stack on this application might fail to build, if a system python package that is not compliant gets chosen to be used instead of the ones installed in pipenv
.
We will get errors like these during installation,
File "/root/.local/share/virtualenvs/rmf-web-lvpjIRYg/lib/python3.10/site-packages/pkg_resources/_vendor/packaging/version.py", line 266, in __init__
│ [pipenv.exceptions.InstallError]: raise InvalidVersion(f"Invalid version: '{version}'")
│ [pipenv.exceptions.InstallError]: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '1.1build1'
The version 1.1build1
is not PEP440 compliant.
Steps to reproduce the bug
- update
setuptools
version inPipfile.lock
to be >=v66.0.0
pnpm install
Suggestion
For now, rollback to v65.6.3
, where we will get warnings, but it will still install successfully,
Warning: /home/rmf-web/.venv/lib/python3.10/site-packages/pkg_resources/__init__.py:116: PkgResourcesDeprecationWarning: 1.1build1 is an invalid version and will not be supported in a future release
Moving forward, we should ensure
- we understand the behavior of mixing system and virtual environment's python packages, specifically overlaying venv over ROS 2 debian installed python packages, and overlaying produces the desired behavior
- either create put together a single virtual environment to run both
rmf-web
and the rest ofopen-rmf
. right now we are installing some python dependencies usingpip3 install
foropen-rmf
core libraries, which are most likely different from what we have in ourPipfile.lock
, but compatible at least for now - or release and maintain dependencies with PEP440 compliance (this sounds like a pretty bad idea)