<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 24, 2021 at 4:40 PM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> 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">On 2021-09-24 07:19:03 -0600 (-0600), Alex Schultz wrote:<br>
[...]<br>
> JFYI as I was looking into some other requirements issues<br>
> yesterday, I hit this error with anyjson[0] 0.3.3 as well. It's<br>
> used in a handful of projects[1] and there has not been a release<br>
> since 2012[2] so this might be a problem in xena.  I haven't<br>
> checked the projects respective gates, but just want to highlight<br>
> we'll probably have additional fallout from the setuptools change.<br>
[...]<br>
<br>
Yes, we've also run into similar problems with pydot2 and<br>
funcparserlib, and I'm sure there's plenty more of what is<br>
effectively abandonware lingering in various projects' requirements<br>
lists. The long and short of it is that people with newer versions<br>
of SetupTools are going to be unable to install those, full stop.<br>
The maintainers of some of them may be spurred to action and release<br>
a new version, but in so doing may also drop support for older<br>
interpreters we still test with on some stable branches (this was<br>
the case with funcparserlib).<br></blockquote><div><br></div><div>Apparently, suds-jurko has the same problem, breaking oslo.vmware [1] and thus cinder.</div><div><br></div><div>Dmitry</div><div><br></div><div>[1] <a href="https://review.opendev.org/c/openstack/oslo.vmware/+/813377">https://review.opendev.org/c/openstack/oslo.vmware/+/813377</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>
On the other hand, controlling what version of SetupTools others<br>
have and use isn't always possible, unlike runtime dependencies, so<br>
that really should be a solution of last resort. Making exceptions<br>
to stable branch policy in unusual circumstances such as this seems<br>
like a reasonable and more effective compromise.<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>