opendevreview | Merged openstack/pbr master: Clarify the need for setup.py with PEP517 https://review.opendev.org/c/openstack/pbr/+/817054 | 00:20 |
---|---|---|
*** odyssey4me is now known as Guest5655 | 00:47 | |
*** soniya29|ruck is now known as soniya29|ruck|afk | 05:16 | |
*** ysandeep|out is now known as ysandeep | 06:07 | |
*** gouthamr_ is now known as gouthamr | 06:19 | |
opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add Log Processor module https://review.opendev.org/c/openstack/ci-log-processing/+/817436 | 07:36 |
*** amoralej|off is now known as amoralej | 07:59 | |
*** ysandeep is now known as ysandeep|lunch | 08:09 | |
*** gibi is now known as giblet | 08:22 | |
*** bauzas is now known as bauwser | 08:22 | |
*** ykarel is now known as ykarel|lunch | 08:45 | |
opendevreview | Fabio Verboso proposed openstack/project-config master: Iotronic-pythonclient and Iotronic-UI update. Jobs moved to py38 (set in .zuul.yaml in the project repositories). https://review.opendev.org/c/openstack/project-config/+/817719 | 09:09 |
*** ysandeep|lunch is now known as ysandeep | 09:23 | |
*** soniya29|ruck|afk is now known as soniya29|ruck | 09:47 | |
*** chandankumar is now known as raukadah | 10:05 | |
*** ykarel|lunch is now known as ykarel | 10:25 | |
*** dviroel|afk is now known as dviroel | 10:34 | |
*** lbragstad0 is now known as lbragstad | 11:06 | |
*** rlandy is now known as rlandy|ruck | 11:10 | |
*** ysandeep is now known as ysandeep|afk | 12:01 | |
*** ykarel_ is now known as ykarel | 12:32 | |
*** ysandeep|afk is now known as ysandeep | 12:59 | |
*** amoralej is now known as amoralej|lunch | 13:03 | |
*** jpena|off is now known as jpena | 13:15 | |
opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add log gearman role https://review.opendev.org/c/openstack/ci-log-processing/+/817759 | 13:27 |
*** amoralej|lunch is now known as amoralej | 13:50 | |
*** ykarel is now known as ykarel|away | 14:20 | |
*** efried1 is now known as efried | 14:56 | |
*** dviroel is now known as dviroel|lunch | 15:18 | |
dpawlik | fungi, clarkb: hey. Since we still does not have a community for review the ci-log-processing project, could you just review the initial commit please https://review.opendev.org/c/openstack/ci-log-processing/+/815604 ? | 15:22 |
clarkb | fungi: stephenfin: for some reason removing setup_requires = ['pbr'] from setup() and running install with pep517 hooks causes the PBR metadata and backward compat hooks to be called recursively until we hit a recursion limit. I can reproduce it with our little test (I discovered it with bindep) and I'm quickly getting lost in expected setuptools behavior | 15:22 |
dpawlik | would be good to improve the code in next patchsets and "unlock" moving forward with Opensearch | 15:22 |
clarkb | dpawlik: unfortunately this is why we have been unable to maintain the system ourselves. There isn't enough interest to have critical mass to do reviews and operations. I can't commit to doing that myself hence the decision to split it out | 15:23 |
clarkb | dpawlik: I think you should be looking towards those trying to keep it alive. gmann dansmith etc may have throughts | 15:23 |
clarkb | *thoughts | 15:23 |
dpawlik | clarkb: allright. So I'm writing an email | 15:25 |
dansmith | and/or melwitt, as she already reviewed | 15:25 |
gmann | dpawlik: yeah, let's put it on ML if anyone want to help in review. Also if fungi clarkb wendar tristanC agree then you can add them in core list but it just idea so depends on their agreement and bandwidth. | 15:32 |
gmann | dpawlik: clarkb also we can do single core approval policy here as we have less people helping on this ? | 15:32 |
clarkb | I'm ok with that considering it is already resource constrained. I just don't want to give the impression I'm able to continue to do this since the whole exercise started when we said we couldn't. I'm happy to help review specific things and explain certain decisions/designs/behaviors etc | 15:35 |
gmann | clarkb: sure, I understand that. and helping review/advise will be helpful. | 15:36 |
wendar | I'm happy to review things, but I'm not an expert in Zuul, so don't have the best perspective on this particular service. | 15:37 |
fungi | i've got a bit of time to look over the packaging, metadata and general boilerplate to make sure we don't give the wrong impressions with it | 15:38 |
fungi | dpawlik: i left some notes | 15:46 |
*** ysandeep is now known as ysandeep|dinner | 15:49 | |
dpawlik | thank you fungi | 15:58 |
*** frenzy_friday is now known as frenzyfriday|PTO | 15:59 | |
*** dviroel|lunch is now known as dviroel | 16:25 | |
clarkb | fungi: stephenfin: this is really fun. pbr.core.pbr() calls Distribution.finalize_options which is what calls pbr.core.pbr(). For some reason when we have a setup_requires we don't recurse. I suspect there must be some machinery in setuptools that automatically removes keyword entrypoints from the list if they were supplied with a setup_requires. But I haven't found that yet | 16:28 |
stephenfin | this sounds like the gift that just keeps on giving :) | 16:29 |
clarkb | ya I'm not setting up a "foreground" test env where I can hack up setuptools and try to figure out what it is doing. | 16:37 |
fungi | s/not/now? | 16:40 |
clarkb | ya sorry | 16:41 |
clarkb | With a hacked up version of setuptools I've discovered that thsi does seem to be the case. When it works pbr is no longer in the second pass so we don't recurse further | 16:41 |
clarkb | and pbr is called after the setup_requires entrypoint. I think the setup_requires entrypoint must be filtering things from the list | 16:42 |
clarkb | We can have pbr do the same if not in setup_requires if I can just find out the safe way to do this | 16:42 |
fungi | or have pbr identify when it's being recursed and no-op? | 16:55 |
fungi | though that's a bit more hacky, it may provide a belt-and-braces safeguard against similar issues in the future | 16:56 |
*** ysandeep|dinner is now known as ysandeep | 16:57 | |
*** ysandeep is now known as ysandeep|out | 16:58 | |
*** amoralej is now known as amoralej|off | 17:14 | |
opendevreview | Clark Boylan proposed openstack/pbr master: Allow PEP517 without setup_requires https://review.opendev.org/c/openstack/pbr/+/817794 | 17:19 |
clarkb | stephenfin: fungi ^ that is what I ended up with and it emulates the behavior when called with setup_requires set. I still don't know why the value changes when setup_requires is set (haven't been able to tracke that down), but it does change to None on the second pass and the pbr() call is skipped over preventing recursion | 17:20 |
fungi | that'll be good to integrate because use of setup_requires metadata is now explicitly deprecated | 17:21 |
clarkb | fungi: fwiw so is the keywords entrypoint that pbr relies on as I just discovered when debugging this | 17:21 |
clarkb | fungi: but one step at a time :) | 17:21 |
fungi | yeah | 17:21 |
fungi | fixing those independently should be fine | 17:22 |
*** jpena is now known as jpena|off | 17:41 | |
opendevreview | Clark Boylan proposed openstack/pbr master: Add python2 testing back to PBR https://review.opendev.org/c/openstack/pbr/+/817800 | 18:01 |
clarkb | fungi: stephenfin ^ noticed that when looking at this change. I think that was my mistake. Woops | 18:02 |
*** dviroel is now known as dviroel|brb | 19:10 | |
*** Guest5508 is now known as melwitt | 19:26 | |
*** melwitt is now known as Guest5716 | 19:27 | |
*** Guest5716 is now known as melwitt | 19:32 | |
*** melwitt is now known as jgwentworth | 19:34 | |
*** dviroel|brb is now known as dviroel | 19:59 | |
*** dviroel is now known as dviroel|out | 21:01 | |
opendevreview | Merged openstack/pbr master: Add python2 testing back to PBR https://review.opendev.org/c/openstack/pbr/+/817800 | 21:20 |
clarkb | fungi: stephenfin https://deps.dev/pypi/pbr/5.7.0/dependents that is really neat | 22:32 |
clarkb | shows use outside of openstack | 22:32 |
clarkb | Looks like there are errors in their dataset (lookup nodepool for example) but the pbr set there is neat anyway | 22:35 |
fungi | very neat! | 22:43 |
fungi | there are more users of pbr than that though, i have a package on pypi which only uses pbr as a build-time dependency and not a run-time dependency, so it doesn't appear there | 22:44 |
fungi | looks like that's strictly packages which claim run-time dependency on pbr, which is known to be only a subset of pbr users | 22:45 |
fungi | probably accurate for a lot of other libs which are only ever used as run-time deps though | 22:45 |
clarkb | they also note that it is a summary | 23:04 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!