Open Stack

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 at 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.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)
> >>
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210928/8064c64f/attachment.htm>