*** mhen_ is now known as mhen | 02:57 | |
*** ralonsoh_ is now known as ralonsoh | 08:10 | |
opendevreview | Michał Górny proposed openstack/pbr master: Modernize test_generates_c_extensions to use EXT_SUFFIX, fix PyPy https://review.opendev.org/c/openstack/pbr/+/940773 | 10:29 |
---|---|---|
opendevreview | Michał Górny proposed openstack/pbr master: Modernize tests to use EXT_SUFFIX, fix PyPy https://review.opendev.org/c/openstack/pbr/+/940773 | 10:31 |
*** ralonsoh_ is now known as ralonsoh | 10:31 | |
opendevreview | Michał Górny proposed openstack/pbr master: Use sysconfig for sitedir path in test_wsgi https://review.opendev.org/c/openstack/pbr/+/940778 | 11:38 |
opendevreview | Michał Górny proposed openstack/pbr master: Use sysconfig for sitedir path in test_wsgi https://review.opendev.org/c/openstack/pbr/+/940778 | 13:51 |
*** ralonsoh_ is now known as ralonsoh | 15:15 | |
cardoe | fungi: another stupid idea... removing +x on setup.py once projects have pyproject.toml? | 15:37 |
fungi | cardoe: you'll see the series i linked earlier does that, yes | 15:39 |
cardoe | I 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 |
fungi | though it doesn't stop them from doing `python3 setup.py ...` | 15:40 |
cardoe | yeah true. And the person I'm trying to stop will absolutely do that. | 15:40 |
fungi | cardoe: good point, i'll revisit the pyproject spec and see if that's a setuptools-specific field instead of the standardized one | 15:41 |
fungi | cardoe: 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 spec | 15:46 |
cardoe | ah okay. | 15:47 |
fungi | cardoe: 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 accordingly | 15:48 |
cardoe | so this is stuff we can do in projects today? or will this depend on something else to happen? | 15:49 |
fungi | the 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 |
fungi | cardoe: 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 |
opendevreview | Daniel Bengtsson proposed openstack/oslo.service master: Add comprehensive backend system documentation. https://review.opendev.org/c/openstack/oslo.service/+/940664 | 15:50 |
cardoe | yeah that makes sense. That's ultimately what I'm looking for as well. What's the recommended minimal set | 15:52 |
fungi | that'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 least | 15:53 |
fungi | we 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 clean | 15:54 |
opendevreview | Daniel Bengtsson proposed openstack/oslo.service master: Add comprehensive backend system documentation. https://review.opendev.org/c/openstack/oslo.service/+/940664 | 15:54 |
clarkb | I'm not even sure I would call them workarounds | 16:00 |
clarkb | the python3.6 issue is probably the only thing that needs working around now? | 16:00 |
fungi | yeah, that's the main thing i'm referring to | 16:03 |
fungi | well, and the need to declare dependencies as dynamic metadata if keeping them in requirements.txt | 16:03 |
fungi | and 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 |
clarkb | and that is only necessary if your directory structure is "wrong" right? | 16:07 |
clarkb | I think if we moved to src/bindep it would just work in bindep? | 16:07 |
clarkb | maybe that is worthy of an experiment too | 16:07 |
opendevreview | Michał Górny proposed openstack/pbr master: Use sysconfig for sitedir path in test_wsgi in py3 https://review.opendev.org/c/openstack/pbr/+/940778 | 16:10 |
fungi | clarkb: i think it still chokes on subdirectories without an __init__.py file | 16:27 |
fungi | but worth testing, yes | 16:27 |
fungi | clarkb: 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 |
fungi | granted, i only tried it with python 3.13, i'll push up a change to see if it works on older interpreters | 16:34 |
clarkb | what did you change? I don't think anything chagned with the pbr relese related to that | 16:34 |
fungi | clarkb: removed the tool.setuptools.packages list | 16:36 |
clarkb | I wonder if it could be related to using pyproject-build? | 16:37 |
fungi | i.e. https://review.opendev.org/c/opendev/bindep/+/940812 | 16:37 |
fungi | well, i don't think nox uses pyproject-build | 16:37 |
fungi | but i did test with pyproject-build and it was fine | 16:38 |
hberaud[m] | There is no meeting today? | 17:07 |
damani[m] | #startmeeting | 17:13 |
opendevmeet | damani[m]: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' | 17:13 |
damani[m] | #startmeeting oslo | 17:15 |
opendevmeet | Meeting 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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:15 |
opendevmeet | The 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 |
gmann | o/ | 17:15 |
JayF | o/ | 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 |
gmann | damani[m]: can you please point me to the agenda? this one? https://etherpad.opendev.org/p/epoxy-oslo-meeting-tracking#L166 | 17:17 |
damani[m] | hberaud, checking https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22+deprecate+status:open+author:hberaud@redhat.com | 17:18 |
gmann | I have couple of topic to discuss so wanted to add in agenda also for future reference | 17:18 |
damani[m] | gmann, ok | 17:19 |
hberaud[m] | gmann: yeah that's the right link | 17:19 |
gmann | thanks | 17:19 |
damani[m] | #topic oslo is in PTL election for F (2025.2) cycle | 17:19 |
gmann | so oslo did not meet the DPL criteria to continue next cycle | 17:20 |
gmann | #link https://review.opendev.org/c/openstack/governance/+/939485 | 17:20 |
gmann | and it is up for PTL election | 17:20 |
gmann | #link https://review.opendev.org/c/openstack/election/+/940415 | 17:21 |
gmann | damani[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 |
gmann | perfect, 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 |
gmann | thanks again | 17:23 |
damani[m] | #meeting time in etherpad | 17:23 |
gmann | yeah, this is a request to have exact meeting time/day in etherpad that will be a easy ref to know meeting | 17:24 |
damani[m] | #topic meeting time in etherpad | 17:24 |
damani[m] | not easy | 17:24 |
damani[m] | again we can change the time | 17:24 |
gmann | currently we have to figure out time based on alternate meeting and day also | 17: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 |
gmann | I mean, if we can write day/time as per when meeting happening. | 17:25 |
gmann | not changing the time | 17:25 |
damani[m] | i can send again a mail to find a new time | 17:25 |
gmann | oh, I did not mean to find new time | 17:25 |
gmann | just to write day/time in etherpad what we already selected | 17:26 |
damani[m] | ok | 17:26 |
damani[m] | you mean instead R-8 (Feb 03 - Feb 07) | 17:26 |
gmann | for example. for this TX meeting we can write 5th Feb 17:00 UTC and for next TZ that day/time | 17:26 |
gmann | s/TX/TZ | 17: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 |
gmann | thanks, that will be easy for new member also to know exact time | 17:29 |
damani[m] | #topic maintenance of openstackdocstheme | 17:29 |
gmann | this is topic i added in previous meeting but I think it was not discussed yet | 17:30 |
damani[m] | yes right | 17:30 |
gmann | #link https://etherpad.opendev.org/p/epoxy-oslo-meeting-tracking#L94 | 17:30 |
gmann | I wrote detail here, it came up in TC meeting last month or long back | 17:30 |
gmann | gtema is volunteering to help to maintain openstackdocstheme | 17:31 |
gmann | I think tkajinam already +1 on the idea in etherpad | 17:31 |
damani[m] | ok | 17:31 |
gmann | if everyone else is ok then I can start the paper work in project-config acl side | 17:31 |
hberaud[m] | I already agreed weeks ago on the etherpad too | 17:32 |
gmann | basically we need to add a new core group for openstackdocstheme where we can add gtema + current oslo-core | 17:32 |
gmann | hberaud[m]: oh, perfect. sorry I did not notice | 17:32 |
hberaud[m] | np | 17:32 |
damani[m] | i have also add my +1 in the document | 17:32 |
gmann | cool | 17:32 |
gmann | I 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 |
gmann | thank | 17:33 |
gmann | that is all form me on this topic | 17:33 |
damani[m] | #topic open discussion | 17:33 |
damani[m] | someone would like to discuss about something else? | 17:34 |
hberaud[m] | nope | 17:34 |
gmann | nothing from me | 17:34 |
damani[m] | ok | 17:34 |
damani[m] | seems we are done for today | 17:34 |
JayF | One quick thing | 17:34 |
damani[m] | yes | 17:34 |
JayF | can we please move forward either https://review.opendev.org/c/openstack/oslo.utils/+/930379 or https://review.opendev.org/c/openstack/oslo.utils/+/937037 | 17:35 |
damani[m] | JayF, looking | 17:35 |
JayF | with 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] | ack | 17:36 |
damani[m] | so that one https://review.opendev.org/c/openstack/oslo.utils/+/937037 | 17:36 |
damani[m] | is a duplicate | 17:36 |
damani[m] | right? | 17:36 |
JayF | they both do the same thing slightly different ways | 17:36 |
JayF | I obviously prefer mine but more than anything else I want one of them to land :) | 17:36 |
JayF | mine was first but at this point that doesn't matter | 17: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 |
JayF | put it on the gerrit review and I'll revise today | 17:37 |
JayF | in a video meeting too and can't multitask that r/n | 17:37 |
gmann | JayF: you are already/always :) | 17:39 |
hberaud[m] | JayF: yours is more complete | 17: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] | #endmeeting | 17:43 |
opendevmeet | Meeting ended Wed Feb 5 17:43:57 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:43 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/oslo/2025/oslo.2025-02-05-17.15.html | 17:43 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/oslo/2025/oslo.2025-02-05-17.15.txt | 17:43 |
opendevmeet | Log: https://meetings.opendev.org/meetings/oslo/2025/oslo.2025-02-05-17.15.log.html | 17:43 |
hberaud[m] | Thanks damani | 17:44 |
gmann | thanks everyone | 17:44 |
opendevreview | Michał Górny proposed openstack/pbr master: Use sysconfig for sitedir path in test_wsgi in py3 https://review.opendev.org/c/openstack/pbr/+/940778 | 17:52 |
opendevreview | Merged openstack/futurist master: deprecate eventlet based classes (green executors) https://review.opendev.org/c/openstack/futurist/+/939361 | 19:01 |
opendevreview | Merged openstack/oslo.cache master: deprecate using memcache_pool backend into an eventlet env. https://review.opendev.org/c/openstack/oslo.cache/+/940429 | 19:03 |
opendevreview | Merged openstack/oslo.utils master: deprecate the eventletutils module https://review.opendev.org/c/openstack/oslo.utils/+/939233 | 19:18 |
opendevreview | Merged openstack/oslo.rootwrap master: deprecate eventlet monkey patching with oslo.rootwrap https://review.opendev.org/c/openstack/oslo.rootwrap/+/940371 | 19:38 |
JayF | it 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'd | 20:23 |
JayF | damani[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 |
dansmith | JayF: I was commenting on the original version and the assertion that it's "preferred" because I do not prefer | 21:06 |
dansmith | JayF: but as I just commented, I'm not a core and have no vote, so I'm definitely not holding you up | 21:06 |
JayF | dansmith: 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 |
dansmith | what I'm annoyed at is that it was ever held up on account of f-strings, if that is what happened | 21:06 |
JayF | dansmith: I also treat you like a core on ~everything because I assume you have core on everything :P | 21:06 |
JayF | tbh I think it was held up on being low priority/not urgent or important | 21:07 |
JayF | and always being on the bottom of lists | 21:07 |
clarkb | as 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 python | 21:07 |
dansmith | you mean I just talk like an asshat in all settings so you assume I'm an asshat :) | 21:07 |
clarkb | that is probably less of an issue here, but its an easy trap to fall into I've found | 21:07 |
dansmith | clarkb: another good reason | 21:07 |
JayF | dansmith: that's my begrudging way of saying I respect your opinion; even if (and sometimes especially if) we disagree | 21:07 |
dansmith | I personally find them easier to read in very few situations but quickly get way out of control as people put expressions and loops in them | 21:08 |
dansmith | JayF: I picked up on that and replied with self-deprecating asshat-awareness | 21:08 |
JayF | lol | 21:08 |
clarkb | my 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 breaks | 21:08 |
dansmith | yup | 21:08 |
JayF | I 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 |
dansmith | definitely for something as useful and unoffensive as this | 21:09 |
JayF | if 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 |
dansmith | I've already arranged to be buried clutching physical media containing a copy of python2 and the BTTF trilogy | 21:10 |
* JayF stares at the amber retro monitor within arms reach of him r/n | 21:17 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!