<div dir="ltr"><div dir="ltr">On Fri, Sep 24, 2021 at 9:22 PM Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Gibi!<br>
<br>
Thanks for bringing this up.<br>
<br>
As a distro package maintainer, here's my view.<br>
<br>
On 9/22/21 2:11 PM, Balazs Gibizer wrote:<br>
> Option 1: Bump the major version of the decorator dependency on stable.<br>
<br>
Decorator 4.0.11 is even in Debian Stretch (currently oldoldstable), for<br>
which I don't even maintain OpenStack anymore (that's OpenStack<br>
Newton...). So I don't see how switching to decorator 4.0.0 is a<br>
problem, and I don't understand how OpenStack could be using 3.4.0 which<br>
is in Jessie (ie: 6 years old Debian release).<br>
<br>
PyPi says Decorator 3.4.0 is from 2012:<br>
<a href="https://pypi.org/project/decorator/#history" rel="noreferrer" target="_blank">https://pypi.org/project/decorator/#history</a><br>
<br>
Do you have your release numbers correct? If so, then switching to<br>
Decorator 4.4.2 (available in Debian Bullseye (shipped with Victoria)<br>
and Ubuntu >=Focal) looks like reasonable to me... Sticking with 3.4.0<br>
feels a bit crazy (and I wasn't aware of it).<br></blockquote><div><br></div><div>Irrelevant now because there are several more packages affected, not just Decorator.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Option 2: Pin the setuptools version during tox installation<br>
<br>
Please don't do this for the master branch, we need OpenStack to stay<br>
current with setuptools (yeah, even if this means breaking changes...).<br></blockquote><div><br></div><div>Pretty sure no one has suggested pinning on master.</div><div><br></div><div>(And the subject of this email includes "stable", twice!)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For already released OpenStack: I don't mind much if this is done (I<br>
could backport fixes if something breaks).<br></blockquote><div><br></div><div>+1, I've posted this: <a href="https://review.opendev.org/c/openstack/requirements/+/810859">https://review.opendev.org/c/openstack/requirements/+/810859</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Option 3: turn off lower-constraints testing<br>
<br>
I already expressed myself about this: this is dangerous as distros rely<br>
on it for setting lower bounds as low as possible (which is always<br>
preferred from a distro point of view).<br></blockquote><div><br></div><div>How does this option help for the specific problem in hand?  Namely:</div><div><br></div><div>- setuptools >=58.0.0 does not support use_2to3 option</div><div><br></div><div>- several packages that are pulled into OpenStack stable builds need use_2to3.</div><div><br></div><div>(Not saying it doesn't; I'm just ignorant here and would appreciate further explanation.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Option 4: utilize pyproject.toml[6] to specify build-time requirements<br>
<br>
I don't know about pyproject.toml.<br>
<br>
Just my 2 cents, hoping it's useful,<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</blockquote></div></div>