[stable][requirements][zuul] unpinned setuptools dependency on stable
balazs.gibizer at est.tech
Wed Sep 22 16:06:49 UTC 2021
On Wed, Sep 22 2021 at 08:39:03 AM -0700, Clark Boylan
<cboylan at sapwetik.org> wrote:
> On Wed, Sep 22, 2021, at 5:11 AM, Balazs Gibizer wrote:
>> The root of the problem is that we always use the latest setuptools
>> our CI testing even on old stable branches. Zuul's ensure-tox
>> installs tox which installs the virtualenv package which bundles the
>> latest setuptools package. This happens without applying any
>> constraints. Then tox is used to install the project's dependencies
>> under lower or upper constraints with the unconstrained setuptools
>> During and after yesterday's nova meeting  we discussed possible
>> Option 1: Bump the major version of the decorator dependency on
>> * easy to implement
>> * might against the policy / breaks downstream packagers
>> * needs to be done in each affected project separately
>> * not future proof. After a future setuptools release we can see a
>> similar break with another of our dependencies.
>> @Stable Cores: how do you feel about such bump?
>> Option 2: Pin the setuptools version during tox installation
>> * single solution for all affected projects
>> * future proof against breaks introduced by future setuptools
>> * complex change as it probably requires to extend the base task in
>> zuul itself
> Note as mentioned during the meeting yesterday I believe you actually
> need to pin virtualenv during the tox installation. If you want to
> pin setuptools it needs to happen when tox creates its virtualenvs.
> One major con to this approach is now you've stopped testing that
> your software can deploy with newer versions of setuptools. It
> doesn't work right this moment, but as circumstances change you'll be
> without up to date information.
I agree not to pin this on master. We need to support the latest and
greatest on master. But on stable I don't see the problem saying we
only support the tooling version that was the latest when the major
release was created.
>> Option 3: turn off lower-constraints testing
>> * easy to implement
>> * some of us want to get rid of lower constraints anyhow
>> * needs per project changes
>> * not future proof against similar break affecting our upper
>> constraints on old stable branches.
>> Option 4: utilize pyproject.toml to specify build-time
>> Unfortunately, I'm not sure if it is possible to restrict the
>> setuptools version with it
>> As a side note I tried applying [tox]requires in tox.ini to restrict
>> setuptools version but It does not seem to take effect in our
> This didn't work because the requires specification seems to only
> affect the meta venv that tox uses to bootstrap itself if necessary
> . Basically this pinned setuptools in the wrong virtualenv. This
> might work if you pinned virtualenv here as suggested above.
Thanks for the pointers. I think I managed to make this work locally.
We will see if it works in CI too when  goes through the check
More information about the openstack-discuss