PEP440 compliance and setuptools >=66.0.0, installation failure

[aaronchongth]

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

1. update setuptools version in Pipfile.lock to be >= v66.0.0
2. 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 of open-rmf. right now we are installing some python dependencies using pip3 install for open-rmf core libraries, which are most likely different from what we have in our Pipfile.lock, but compatible at least for now
• or release and maintain dependencies with PEP440 compliance (this sounds like a pretty bad idea)