<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 22, 2021 at 6:13 AM Balazs Gibizer <balazs.gibizer@est.tech> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
<br>
The latest setuptools (58.0) removed support for "use_2to3" [1] <br>
(deprecated since 46.2). Many OpenStack modules defines <br>
decorator==3.4.0 as lower constraints[2]. However, decorator 3.4.0 <br>
cannot be installed anymore with the latest setuptool as it depends on <br>
"use_2to3".<br>
<br></blockquote><div><br></div><div>JFYI as I was looking into some other requirements issues yesterday, I hit this error with anyjson[0] 0.3.3 as well. It's used in a handful of projects[1] and there has not been a release since 2012[2] so this might be a problem in xena.  I haven't checked the projects respective gates, but just want to highlight we'll probably have additional fallout from the setuptools change.</div><div><br></div><div>[0] <a href="https://github.com/pypa/setuptools/issues/1120#issuecomment-919239967">https://github.com/pypa/setuptools/issues/1120#issuecomment-919239967</a></div><div>[1] <a href="https://codesearch.opendev.org/?q=anyjson&i=nope&literal=nope&files=&excludeFiles=&repos=">https://codesearch.opendev.org/?q=anyjson&i=nope&literal=nope&files=&excludeFiles=&repos=</a></div><div>[2] <a href="https://pypi.org/project/anyjson/#history">https://pypi.org/project/anyjson/#history</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">
On master, this can be solved easily by bumping the dependency to <br>
decorator 4.0.0. On stable/xena we can still solve it the same way with <br>
a new RC. But on older stable branches such solution might be against <br>
the stable policy as it would require a major bump on our dependencies.<br>
<br>
This issue is not limited to lower-constraints testing it just hit us <br>
there first. A similar break could happen in our upper constraints as <br>
well on old stable branches.<br>
<br>
The root of the problem is that we always use the latest setuptools in <br>
our CI testing even on old stable branches. Zuul's ensure-tox task[4] <br>
installs tox which installs the virtualenv package which bundles the <br>
latest setuptools package. This happens without applying any <br>
constraints. Then tox is used to install the project's dependencies <br>
under lower or upper constraints with the unconstrained setuptools <br>
available.<br>
<br>
During and after yesterday's nova meeting [3] we discussed possible <br>
solutions.<br>
<br>
Option 1: Bump the major version of the decorator dependency on stable.<br>
Pros:<br>
* easy to implement<br>
Cons:<br>
* might against the policy / breaks downstream packagers<br>
* needs to be done in each affected project[3] separately<br>
* not future proof. After a future setuptools release we can see a <br>
similar break with another of our dependencies.<br>
<br>
@Stable Cores: how do you feel about such bump?<br>
<br>
<br>
Option 2: Pin the setuptools version during tox installation<br>
Pros:<br>
* single solution for all affected projects<br>
* future proof against breaks introduced by future setuptools releases<br>
Cons:<br>
* complex change as it probably requires to extend the base task in <br>
zuul itself<br>
<br>
<br>
Option 3: turn off lower-constraints testing<br>
Pros:<br>
* easy to implement<br>
* some of us want to get rid of lower constraints anyhow<br>
Cons:<br>
* needs per project changes<br>
* not future proof against similar break affecting our upper <br>
constraints on old stable branches.<br>
<br>
<br>
Option 4: utilize pyproject.toml[6] to specify build-time requirements<br>
Unfortunately, I'm not sure if it is possible to restrict the maximum <br>
setuptools version with it<br>
<br>
<br>
As a side note I tried applying [tox]requires in tox.ini to restrict <br>
setuptools version[7] but It does not seem to take effect in our <br>
case[8].<br>
<br>
<br>
@Stable Cores: what do you think what could be the way forward?<br>
<br>
Cheers,<br>
gibi<br>
<br>
<br>
[1] <a href="https://setuptools.pypa.io/en/latest/history.html#v58-0-2" rel="noreferrer" target="_blank">https://setuptools.pypa.io/en/latest/history.html#v58-0-2</a><br>
[2] <br>
<a href="https://codesearch.openstack.org/?q=decorator%3D%3D3.4.0&i=nope&literal=nope&files=&excludeFiles=&repos=" rel="noreferrer" target="_blank">https://codesearch.openstack.org/?q=decorator%3D%3D3.4.0&i=nope&literal=nope&files=&excludeFiles=&repos=</a><br>
[3] <br>
<a href="https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2021-09-21.log.html#t2021-09-21T16:31:49" rel="noreferrer" target="_blank">https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2021-09-21.log.html#t2021-09-21T16:31:49</a><br>
[4] <br>
<a href="https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-tox/tasks/main.yaml#L28" rel="noreferrer" target="_blank">https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-tox/tasks/main.yaml#L28</a><br>
[5] <a href="https://tox.readthedocs.io/en/latest/config.html#conf-requires" rel="noreferrer" target="_blank">https://tox.readthedocs.io/en/latest/config.html#conf-requires</a><br>
[6] <a href="https://www.python.org/dev/peps/pep-0518/" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0518/</a><br>
[7] <a href="https://review.opendev.org/c/openstack/placement/+/810293/1/tox.ini" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/placement/+/810293/1/tox.ini</a><br>
[8] <br>
<a href="https://zuul.opendev.org/t/openstack/build/f78a0300c8734e7c8475309af1d2e1a4/log/tox/lower-constraints-0.log#7" rel="noreferrer" target="_blank">https://zuul.opendev.org/t/openstack/build/f78a0300c8734e7c8475309af1d2e1a4/log/tox/lower-constraints-0.log#7</a><br>
<br>
<br>
<br>
<br>
</blockquote></div></div>