Open Stack

Hi again,

as I see there is no objection yet about using gibi's solution [1] (as I 
already summarized the situation in my previous mail [2]) for a fix for 
similar cases, so with a general stable core hat on, I *suggest* 
everyone to use that solution to pin the setuptools in tox for every 
failing cases (so that to avoid similar future errors as well).

[1] https://review.opendev.org/810461
[2] 
http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025059.html

Előd


On 2021. 09. 27. 14:47, Balazs Gibizer wrote:
>
>
> 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).
>
> ack
>
>>
>>>  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,
>
> Thanks!
>
> Cheers,
> gibi
>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>
>
>