On Fri, Sep 24, 2021 at 9:22 PM Thomas Goirand <zigo@debian.org> wrote:
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:

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).

Irrelevant now because there are several more packages affected, not just Decorator.

> 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...).

Pretty sure no one has suggested pinning on master.

(And the subject of this email includes "stable", twice!)

For already released OpenStack: I don't mind much if this is done (I
could backport fixes if something breaks).

+1, I've posted this: https://review.opendev.org/c/openstack/requirements/+/810859

> 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).

How does this option help for the specific problem in hand?  Namely:

- setuptools >=58.0.0 does not support use_2to3 option

- several packages that are pulled into OpenStack stable builds need use_2to3.

(Not saying it doesn't; I'm just ignorant here and would appreciate further explanation.)

> 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,

Thomas Goirand (zigo)