Hi Gibi! Thanks for bringing this up. As a distro package maintainer, here's my view. On 9/22/21 2:11 PM, Balazs Gibizer wrote:
Option 1: Bump the major version of the decorator dependency on stable.
Decorator 4.0.11 is even in Debian Stretch (currently oldoldstable), for which I don't even maintain OpenStack anymore (that's OpenStack Newton...). So I don't see how switching to decorator 4.0.0 is a problem, and I don't understand how OpenStack could be using 3.4.0 which is in Jessie (ie: 6 years old Debian release). PyPi says Decorator 3.4.0 is from 2012: https://pypi.org/project/decorator/#history Do you have your release numbers correct? If so, then switching to Decorator 4.4.2 (available in Debian Bullseye (shipped with Victoria) and Ubuntu >=Focal) looks like reasonable to me... Sticking with 3.4.0 feels a bit crazy (and I wasn't aware of it).
Option 2: Pin the setuptools version during tox installation
Please don't do this for the master branch, we need OpenStack to stay current with setuptools (yeah, even if this means breaking changes...). For already released OpenStack: I don't mind much if this is done (I could backport fixes if something breaks).
Option 3: turn off lower-constraints testing
I already expressed myself about this: this is dangerous as distros rely on it for setting lower bounds as low as possible (which is always preferred from a distro point of view).
Option 4: utilize pyproject.toml[6] to specify build-time requirements
I don't know about pyproject.toml. Just my 2 cents, hoping it's useful, Cheers, Thomas Goirand (zigo)