[stable][requirements][zuul] unpinned setuptools dependency on stable

Balazs Gibizer balazs.gibizer at est.tech
Mon Sep 27 12:47:48 UTC 2021

On Fri, Sep 24 2021 at 10:21:33 PM +0200, Thomas Goirand 
<zigo at 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:
> 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).

Thanks for the info. So from Debian perspective it is OK to bump the 
decorator version on stable. As others noted in this thread it seems to 
be more than just decorator that broke. :/

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

I've no intention to pin it on master. Master needs to work with the 
latest and greatest. Also on master it is easier to fix / replace the 
dependencies that become broken with new setuptools.

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

More information about the openstack-discuss mailing list