I can now confirm that https://review.opendev.org/c/openstack/requirements/+/810859 fixes my CI use case. (By temporarily using a fork of the requirements repo that includes that change.)
(Fix detail if needed here: https://github.com/projectcalico/networking-calico/pull/64/commits/cbed62824... )
Best wishes. Neil
On Mon, Oct 4, 2021 at 6:28 PM Neil Jerram neil@tigera.io wrote:
Is anyone helping to progress this? I just checked that stable/ussuri devstack is still broken.
Best wishes, Neil
On Tue, Sep 28, 2021 at 9:20 AM Neil Jerram neil@tigera.io wrote:
But I don't think that solution works for devstack, does it? Is there a way to pin setuptools in a stable/ussuri devstack run, except by changing the stable branch of the requirements project?
On Mon, Sep 27, 2021 at 7:50 PM Előd Illés elod.illes@est.tech wrote:
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...
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@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)