Wednesday, 2025-02-05

*** mhen_ is now known as mhen02:57
*** ralonsoh_ is now known as ralonsoh08:10
opendevreviewMichał Górny proposed openstack/pbr master: Modernize test_generates_c_extensions to use EXT_SUFFIX, fix PyPy  https://review.opendev.org/c/openstack/pbr/+/94077310:29
opendevreviewMichał Górny proposed openstack/pbr master: Modernize tests to use EXT_SUFFIX, fix PyPy  https://review.opendev.org/c/openstack/pbr/+/94077310:31
*** ralonsoh_ is now known as ralonsoh10:31
opendevreviewMichał Górny proposed openstack/pbr master: Use sysconfig for sitedir path in test_wsgi  https://review.opendev.org/c/openstack/pbr/+/94077811:38
opendevreviewMichał Górny proposed openstack/pbr master: Use sysconfig for sitedir path in test_wsgi  https://review.opendev.org/c/openstack/pbr/+/94077813:51
*** ralonsoh_ is now known as ralonsoh15:15
cardoefungi: another stupid idea... removing +x on setup.py once projects have pyproject.toml?15:37
fungicardoe: you'll see the series i linked earlier does that, yes15:39
cardoeI also noticed in your bindep change that [entry_points] stayed but when I looked up the docs on that [options]/py_modules it also had one for [options]/entry_points. Should we migrate to that as well?15:40
fungithough it doesn't stop them from doing `python3 setup.py ...`15:40
cardoeyeah true. And the person I'm trying to stop will absolutely do that.15:40
fungicardoe: good point, i'll revisit the pyproject spec and see if that's a setuptools-specific field instead of the standardized one15:41
fungicardoe: looking at https://packaging.python.org/en/latest/specifications/pyproject-toml/#entry-points that's the one we want. options.py_modules is for a setuptools feature (managing its module scanning functionality), which isn't standardized in the spec15:46
cardoeah okay.15:47
fungicardoe: if you look at the next change in the series you'll see those migrate to project.scripts and tool.setuptools.packages in pyproject.toml accordingly15:48
cardoeso this is stuff we can do in projects today? or will this depend on something else to happen?15:49
fungithe reason for switching from files.packages to options.py_modules in setup.cfg was in support of a wider variety of setuptools versions (because bindep is supporting python 3.6 through 3.12 at that point)15:49
fungicardoe: that entire series is an example of things that projects *could* do today, what we've been trying to work out is which of those things we want to recommend (e.g. does it make sense to move dependencies out of requirements.txt?)15:50
opendevreviewDaniel Bengtsson proposed openstack/oslo.service master: Add comprehensive backend system documentation.  https://review.opendev.org/c/openstack/oslo.service/+/94066415:50
cardoeyeah that makes sense. That's ultimately what I'm looking for as well. What's the recommended minimal set15:52
fungithat's exacyly what i'm hoping to collect opinions on in the experimental bindep series. all its tests pass, so these changes are functionally sound at least15:53
fungiwe needed to switch release jobs over from running setup.py to build, and get pbr released with setuptools as an express dependency, but now that those have happened the set of workarounds there is pretty clean15:54
opendevreviewDaniel Bengtsson proposed openstack/oslo.service master: Add comprehensive backend system documentation.  https://review.opendev.org/c/openstack/oslo.service/+/94066415:54
clarkbI'm not even sure I would call them workarounds16:00
clarkbthe python3.6 issue is probably the only thing that needs working around now?16:00
fungiyeah, that's the main thing i'm referring to16:03
fungiwell, and the need to declare dependencies as dynamic metadata if keeping them in requirements.txt16:03
fungiand overriding setuptools attempts to auto-populate the manifest by searching for pythin modules itself (but we already had to do that in setupt.cfg, so it's simply migrating that to pyproject.toml)16:04
clarkband that is only necessary if your directory structure is "wrong" right?16:07
clarkbI think if we moved to src/bindep it would just work in bindep?16:07
clarkbmaybe that is worthy of an experiment too16:07
opendevreviewMichał Górny proposed openstack/pbr master: Use sysconfig for sitedir path in test_wsgi in py3  https://review.opendev.org/c/openstack/pbr/+/94077816:10
fungiclarkb: i think it still chokes on subdirectories without an __init__.py file16:27
fungibut worth testing, yes16:27
fungiclarkb: huh, actually, it seems to "just work" even without bothering with switching to so-called "src layout" (presumably because pbr gets hooked in at the right time now?)16:34
fungigranted, i only tried it with python 3.13, i'll push up a change to see if it works on older interpreters16:34
clarkbwhat did you change? I don't think anything chagned with the pbr relese related to that16:34
fungiclarkb: removed the tool.setuptools.packages list16:36
clarkbI wonder if it could be related to using pyproject-build?16:37
fungii.e. https://review.opendev.org/c/opendev/bindep/+/94081216:37
fungiwell, i don't think nox uses pyproject-build16:37
fungibut i did test with pyproject-build and it was fine16:38
hberaud[m]There is no meeting today?17:07
damani[m]#startmeeting17:13
opendevmeetdamani[m]: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee'17:13
damani[m]#startmeeting oslo17:15
opendevmeetMeeting started Wed Feb  5 17:15:12 2025 UTC and is due to finish in 60 minutes.  The chair is damani[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.17:15
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:15
opendevmeetThe meeting name has been set to 'oslo'17:15
damani[m]hberaud, JayF, gmann, tkajinam, meeting time 17:15
damani[m]hberaud, yes, sorry i was to another meeting 17:15
gmanno/17:15
JayFo/17:15
hberaud[m]o/17:16
damani[m]so next week it's the feature freeze for oslo 17:16
damani[m]if you have some patches some need to be merged before, please ping here 17:17
gmanndamani[m]: can you please point me to the agenda? this one? https://etherpad.opendev.org/p/epoxy-oslo-meeting-tracking#L16617:17
damani[m]hberaud, checking https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22+deprecate+status:open+author:hberaud@redhat.com17:18
gmannI have couple of topic to discuss so wanted to add in agenda also for future reference 17:18
damani[m]gmann, ok17:19
hberaud[m]gmann: yeah that's the right link17:19
gmannthanks17:19
damani[m]#topic oslo is in PTL election for F (2025.2) cycle17:19
gmannso oslo did not meet the DPL criteria to continue next cycle 17:20
gmann#link https://review.opendev.org/c/openstack/governance/+/93948517:20
gmannand it is up for PTL election17:20
gmann#link https://review.opendev.org/c/openstack/election/+/94041517:21
gmanndamani[m]: or anyone else planning to run for PTL?17:21
damani[m]ok for the dpl 17:21
damani[m]gmann, yes why not 17:22
gmannperfect, thanks damani[m], as nomination is started today, feel free to propose your candidacy  17:22
damani[m]gmann, ok, i will do it 17:23
gmannthanks again17:23
damani[m]#meeting time in etherpad17:23
gmannyeah, this is a request to have exact meeting time/day in etherpad that will be a easy ref to know meeting17:24
damani[m]#topic meeting time in etherpad17:24
damani[m]not easy 17:24
damani[m]again we can change the time 17:24
gmanncurrently we have to figure out time based on alternate meeting and day also17:25
damani[m]but for example tkajinam can't at that time 17:25
damani[m]gmann, and for you it's hard earlier 17:25
gmannI mean, if we can write day/time as per when meeting happening. 17:25
gmannnot changing the time17:25
damani[m]i can send again a mail to find a new time 17:25
gmannoh, I did not mean to find new time17:25
gmannjust to write day/time in etherpad what we already selected17:26
damani[m]ok17:26
damani[m]you mean instead R-8 (Feb 03 - Feb 07)17:26
gmannfor example. for this TX meeting we can write 5th Feb 17:00 UTC and for next TZ that day/time17:26
gmanns/TX/TZ17:26
gmann'R-8 (Feb 03 - Feb 07)' -> '5th Feb 17:00 UTC'17:27
damani[m]yes we can add the time and date 17:28
gmannthanks, that will be easy for new member also to know exact time17:29
damani[m]#topic maintenance of openstackdocstheme17:29
gmannthis is topic i added in previous meeting but I think it was not discussed yet17:30
damani[m]yes right 17:30
gmann#link https://etherpad.opendev.org/p/epoxy-oslo-meeting-tracking#L9417:30
gmannI wrote detail here, it came up in TC meeting last month or long back17:30
gmanngtema is volunteering to help to maintain openstackdocstheme17:31
gmannI think tkajinam already +1 on the idea in etherpad17:31
damani[m]ok17:31
gmannif everyone else is ok then I can start the paper work in project-config acl side17:31
hberaud[m]I already agreed weeks ago on the etherpad too17:32
gmannbasically we need to add a new core group for openstackdocstheme where we can add gtema + current oslo-core17:32
gmannhberaud[m]: oh, perfect. sorry I did not notice17:32
hberaud[m]np17:32
damani[m]i have also add my +1 in the document 17:32
gmanncool17:32
gmannI will propose the project-config change and add you all in review along with gtema 17:33
damani[m]sounds good 17:33
damani[m]thanks a lot 17:33
gmannthank17:33
gmannthat is all form me on this topic17:33
damani[m]#topic open discussion17:33
damani[m]someone would like to discuss about something else?17:34
hberaud[m]nope17:34
gmannnothing from me17:34
damani[m] ok17:34
damani[m]seems we are done for today 17:34
JayFOne quick thing17:34
damani[m]yes 17:34
JayFcan we please move forward either https://review.opendev.org/c/openstack/oslo.utils/+/930379 or https://review.opendev.org/c/openstack/oslo.utils/+/93703717:35
damani[m]JayF, looking 17:35
JayFwith ff coming up, that'd be nice to get in for this release and it's been awaiting review for literally months (to the point where someone duped the feature)17:35
hberaud[m]ack17:36
damani[m]so that one https://review.opendev.org/c/openstack/oslo.utils/+/93703717:36
damani[m]is a duplicate 17:36
damani[m]right?17:36
JayFthey both do the same thing slightly different ways17:36
JayFI obviously prefer mine but more than anything else I want one of them to land :)17:36
JayFmine was first but at this point that doesn't matter17:37
damani[m]JayF, just i agree with hberaud it better to use f-string now 17:37
damani[m]JayF, can you change it please?17:37
JayFput it on the gerrit review and I'll revise today17:37
JayFin a video meeting too and can't multitask that r/n17:37
gmannJayF: you are already/always :)17:39
hberaud[m]JayF: yours is more complete17:40
damani[m]JayF, ok, i will do it 17:40
damani[m]something else?17:42
damani[m]seems we are done 17:43
damani[m]thanks a lot everyone for today 17:43
damani[m]#endmeeting17:43
opendevmeetMeeting ended Wed Feb  5 17:43:57 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:43
opendevmeetMinutes:        https://meetings.opendev.org/meetings/oslo/2025/oslo.2025-02-05-17.15.html17:43
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/oslo/2025/oslo.2025-02-05-17.15.txt17:43
opendevmeetLog:            https://meetings.opendev.org/meetings/oslo/2025/oslo.2025-02-05-17.15.log.html17:43
hberaud[m]Thanks damani 17:44
gmannthanks everyone 17:44
opendevreviewMichał Górny proposed openstack/pbr master: Use sysconfig for sitedir path in test_wsgi in py3  https://review.opendev.org/c/openstack/pbr/+/94077817:52
opendevreviewMerged openstack/futurist master: deprecate eventlet based classes (green executors)  https://review.opendev.org/c/openstack/futurist/+/93936119:01
opendevreviewMerged openstack/oslo.cache master: deprecate using memcache_pool backend into an eventlet env.  https://review.opendev.org/c/openstack/oslo.cache/+/94042919:03
opendevreviewMerged openstack/oslo.utils master: deprecate the eventletutils module  https://review.opendev.org/c/openstack/oslo.utils/+/93923319:18
opendevreviewMerged openstack/oslo.rootwrap master: deprecate eventlet monkey patching with oslo.rootwrap  https://review.opendev.org/c/openstack/oslo.rootwrap/+/94037119:38
JayFit would be nice to get reviews on https://review.opendev.org/c/openstack/oslo.messaging/+/940495 -- adamcarthur5 is working to improve the test simulator, he'll be using it to test and prototype the implementation of the send-notifications-to-different-queues feature work we have roughly spec'd20:23
JayFdamani[m] hberaud[m]: So I'm a little confused: I was already using f-strings in that patch, and now dansmith commented saying he prefers the other method. Please let me know how to proceed ( re: https://review.opendev.org/c/openstack/oslo.utils/+/930379/10..11/oslo_utils/imageutils/cli.py#b63 ) 21:04
dansmithJayF: I was commenting on the original version and the assertion that it's "preferred" because I do not prefer21:06
dansmithJayF: but as I just commented, I'm not a core and have no vote, so I'm definitely not holding you up21:06
JayFdansmith: I just replied basically agreeing with you on the meta-point (we should enforce style with lint; and this seems like a style nit)21:06
dansmithwhat I'm annoyed at is that it was ever held up on account of f-strings, if that is what happened21:06
JayFdansmith: I also treat you like a core on ~everything because I assume you have core on everything :P 21:06
JayFtbh I think it was held up on being low priority/not urgent or important21:07
JayFand always being on the bottom of lists21:07
clarkbas a data point we try to avoid f strings because when you write ansible module code (and probably elsewhere too) you end up unexpectedly breaking on them when things run on old python21:07
dansmithyou mean I just talk like an asshat in all settings so you assume I'm an asshat :)21:07
clarkbthat is probably less of an issue here, but its an easy trap to fall into I've found21:07
dansmithclarkb: another good reason21:07
JayFdansmith: that's my begrudging way of saying I respect your opinion; even if (and sometimes especially if) we disagree21:07
dansmithI personally find them easier to read in very few situations but quickly get way out of control as people put expressions and loops in them21:08
dansmithJayF: I picked up on that and replied with self-deprecating asshat-awareness21:08
JayFlol21:08
clarkbmy personal stanceon this stuff is largely informed by pbr and I will say that writing code that still runs under python2 is not difficult particularly with CI to catch problems. But everyone is super eager to use new things or drop old python as soon as they feel possible and 9 times out of 10 we discover a corner case that breaks21:08
dansmithyup21:08
JayFI am a big fan of ... if it works land it, and CI should be the arbiter of if it works (with obvious exceptions like API changes/interfaces which need a little more care) 21:09
dansmithdefinitely for something as useful and unoffensive as this21:09
JayFif you don't trust CI to know if it works or not, it'll break eventually, the only question is how far away that is 21:09
clarkb(note I'm not advocating for python2 in the general case just want ot illustrate it continues to be possible if necessary)21:09
dansmithI've already arranged to be buried clutching physical media containing a copy of python2 and the BTTF trilogy21:10
* JayF stares at the amber retro monitor within arms reach of him r/n21:17

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!