| clarkb | tonyb: you mean the universal wheels require a newer version of python? that seems like a bug in the package tooling, but I'm also not surprised given the historical behaviors of those packages nad also wouldn't expect upstream to fix it | 00:36 |
|---|---|---|
| tonyb | the universal wheels themselves are valid. The problem is that wheels built with "newer" (I don't know exactly what newer means) tools place the dist-info into a folder that is the cannonicaly correct name as opposed to older tools use the package name (oslo_utils vs oslo.utils)[1,2]. | 01:42 |
| tonyb | So in the older environments even though pip install oslo.utils works, and import oslo_utils is fine. Some parts (at least pkg_resources) will error out because it can't find the dist-info for oslo.utils which is listed in 'Requires-Dist'. | 01:43 |
| tonyb | I don't recall what I was going to add as footnotes [1] and [2] | 01:44 |
| tonyb | clarkb: ^^ | 01:44 |
| tonyb | for example: `pkg_resources.DistributionNotFound: The 'oslo.messaging>=14.2.0' distribution was not found and is required by neutron-lib` olso.messaging if very much installed. | 01:47 |
| Clark[m] | I wonder if the pkg_resources replacement works in all cases. Probably too late to switch to fix this issue if so but may be good motivation to keep on the replacement process | 01:58 |
| tonyb | Clark[m]: If the issues were confined to openstack/requirements testing, then we could deal with it. But projects (keystone and designate) hit the problem outside of CI | 03:19 |
| tonyb | so fixing it properly will be hard and complex so for caracal I'm a little inclined to just give up. We also see it in dalmatian so we're going to get out of it altogether. | 03:21 |
| elodilles | tonyb: the moving itself won't create releases, but some teams are preparing their final caracal stable releases, hopefully this week as end of next week is the planned transition date: oct 24th. (tip of stable/2024.1 branches will be tagged with 2024.1-eom and NOT the latest release out of the branch. so there should be a moderate number of final releases this week, i'd say) | 07:15 |
| tonyb | okay noted. I'll see what I can do to get things working again | 07:23 |
| elodilles | tonyb: to be honest, i tried to look into the issue when octavia reported their related bug ( https://bugs.launchpad.net/octavia/+bug/2121578 ) but i didn't get far with it due to lack of time as we were mostly busy with preparing Flamingo release :S | 08:28 |
| tonyb | fair enough. I have a couple of ideas , ..... well one really. I'm not sure how hard or long it'll take though | 08:36 |
| opendevreview | Merged openstack/releases master: Release Rally 5.0.1 https://review.opendev.org/c/openstack/releases/+/963349 | 09:29 |
| *** haleyb|out is now known as haleyb | 12:59 | |
| opendevreview | Dmitriy Rabotyagov proposed openstack/releases master: Create OpenStack-Ansible Beta release for Flamingo https://review.opendev.org/c/openstack/releases/+/963967 | 14:27 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/releases master: Release OpenStack-Ansible for Epoxy https://review.opendev.org/c/openstack/releases/+/963968 | 14:28 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/releases master: Release OpenStack-Ansible for Dalmatian https://review.opendev.org/c/openstack/releases/+/963969 | 14:29 |
| *** gmaan_pto is now known as gmaan | 16:00 | |
| fungi | tonyb: catching up, it's any packages built with a ~1.5-year-old setuptools or later (v66 i think?), but through a quirk of tooling we had been building with an older setuptools until we switched from calling setup.py directly to using pyproject-build which resulted in using latest setuptools | 23:49 |
| opendevreview | Brian Haley proposed openstack/releases master: [Neutron] Release a new 2025.2 version: 27.0.1 https://review.opendev.org/c/openstack/releases/+/964097 | 23:49 |
| fungi | people keep re-discovering this problem, i've had this same discussion probably half a dozen times at this point | 23:51 |
| opendevreview | Brian Haley proposed openstack/releases master: [Neutron] Release a new 2025.1 version: 26.0.2 https://review.opendev.org/c/openstack/releases/+/964098 | 23:53 |
| fungi | in other places this bit us, we just switched to looking for both the original and normalized names and take whichever happens to exist | 23:53 |
| fungi | sadly, setuptools merged a fix for the problem, but didn't backport it | 23:54 |
| tonyb | fungi: That explains what changed, I guess I'm looking for a way forward. Anything we build+release+publish that needs to work with old/buggy pkg_resources is broken | 23:55 |
| fungi | there was basically one major version of setuptools where it's regressed, and that's where we keep hitting the error | 23:55 |
| fungi | but nobody was able to convince them to do a point release with the backported patch | 23:56 |
| tonyb | Yeah. They didn't say no, they just didn't do it. | 23:56 |
| opendevreview | Brian Haley proposed openstack/releases master: [Neutron] Release a new 2024.2 version: 25.2.1 https://review.opendev.org/c/openstack/releases/+/964099 | 23:56 |
| fungi | and yes, it's basically just an unfixed bug in setuptools, so without fixing setuptools anything we do will only be a hacky workaround anyway | 23:57 |
| fungi | or rather, unfixed in one major setuptools version | 23:57 |
| fungi | so of course their answer is "just use newer setuptools... oh you're on an (eol) python version that the fixed setuptools doesn't support? you should also upgrade python" | 23:58 |
| tonyb | fungi: I guess I'm wondering if its worth updating out tools so that if we're releasing from caracal or dalmation to do $magic, so that we generate wheels that work in those releases. In theory constraints and other tools mean that we shoudln't use caracal:oslo.* outside of caracal | 23:59 |
| fungi | maybe... we'd probably need to run those jobs on an older platform/python though to be possible | 23:59 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!