| opendevreview | Clark Boylan proposed openstack/pbr master: Use pyproject.toml https://review.opendev.org/c/openstack/pbr/+/938331 | 17:35 |
|---|---|---|
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 17:35 |
| clarkb | fungi: ^ thats the hackyness I've come up with | 17:35 |
| clarkb | I have no idea if it works because I'm a bit afraid to let something like that run on my local machine first pass (or at all) | 17:35 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Use pyproject.toml https://review.opendev.org/c/openstack/pbr/+/938331 | 17:41 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 17:41 |
| fungi | you could create a temporary user or run it in a container maybe, but yeah i'd just lean on zuul and not worry about it | 17:43 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Use pyproject.toml https://review.opendev.org/c/openstack/pbr/+/938331 | 18:03 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 18:03 |
| clarkb | hrm my monkey patching isn't working properly | 18:27 |
| clarkb | https://zuul.opendev.org/t/openstack/build/5dece5654e3b447082339fec831e2380/log/job-output.txt#694 | 18:28 |
| clarkb | fungi: ^ any idea why the patching at https://review.opendev.org/c/openstack/pbr/+/938331/5/pbr/build.py line 162 and beyond doesn't seem to owkr? | 18:28 |
| clarkb | I do that whole dance there to try and make the existing methods work via the existing build_meta._BACKEND object | 18:29 |
| clarkb | and it does seem to add the method to the object its just not calling it with the build_meta backend passed in as self? | 18:30 |
| clarkb | oh I see I thought I was using the definitions setuptools was doing but it has to do with binding the method to the object first | 18:46 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Use pyproject.toml https://review.opendev.org/c/openstack/pbr/+/938331 | 18:58 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 18:58 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Use pyproject.toml https://review.opendev.org/c/openstack/pbr/+/938331 | 19:49 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 19:49 |
| clarkb | fungi: so editable_wheel isn't a valid command in setuptools 59.x | 20:01 |
| clarkb | which means after porting all of that and getting past the initial failures we are still failing | 20:01 |
| clarkb | I'm not sure what the best option is here sicne I suspect backporting editable_wheel may be too much effort. Another option may be to say that editable installs are not possible on python3.6 with latest pip for that platform? | 20:02 |
| clarkb | I'll have to think about this a bit but I suspect we'll end up in a position like that (which may break devstack for older platforms) | 20:02 |
| fungi | mmm, can pbr still fall back on its old behavior in those cases, or is it that pip is forcing it whether we want it or not? | 20:04 |
| fungi | i.e. say no editable installs on python<3.7 when using pyproject.toml | 20:04 |
| fungi | or even just document that to use pyproject.toml files with pbr you must be on python>=3.7 | 20:06 |
| fungi | and update the documentation to require setuptools>=60 | 20:07 |
| fungi | mmm, actually https://docs.openstack.org/pbr/latest/user/using.html#pyproject-toml already says setuptools>=64 | 20:07 |
| fungi | i guess the problem is that pip will react automatically to the presence of a pyproject.toml file | 20:08 |
| clarkb | it is pip forcing | 20:09 |
| fungi | but regardless we already don't expect pbr's pyproject.toml support to work with a setuptools that old | 20:09 |
| clarkb | I actualyl went down that avenue first and they even have does saying pip won't respect the legacy behavior | 20:09 |
| clarkb | though I guess I didn't check the specific version python3.6 is using and we can try and orce the legacy behavior there and see what happens | 20:09 |
| clarkb | fungi: right the problem is in switching PBR itself to pyproject.toml | 20:10 |
| fungi | yeah, because it uses itself | 20:10 |
| clarkb | there isn't a way to say "This package shouldn'y use pyproject.toml" fi the file is present and the tool (pip etc) support it | 20:10 |
| clarkb | but may be we can do something like set the env var that says use legacy editable installs and hand wave past it | 20:10 |
| clarkb | it will take me a bit to unwind back to a state where we can test that way | 20:10 |
| clarkb | or I guess I can test with just that flag then clean the change up if that works | 20:11 |
| fungi | that might be faster for figuring out if it's even a viable option | 20:12 |
| clarkb | --config-settings editable_mode=compat seems to be the pip flag | 20:12 |
| clarkb | I think there is an env var too maybe which would be better | 20:12 |
| clarkb | because then it can be exported into the entire test stack which also install pbr and friends | 20:13 |
| fungi | yeah, it would be used recursively then | 20:13 |
| fungi | because otherwise you're dealing with subprocesses that don't necessarily get the option passed along | 20:13 |
| clarkb | PIP_CONFIG_SETTINGS='editable_mode=compat' maybe | 20:14 |
| clarkb | pip 21.3.1 is the version being used I think fwiw | 20:17 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Use pyproject.toml https://review.opendev.org/c/openstack/pbr/+/938331 | 20:19 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 20:19 |
| clarkb | that is incomplete because there is a whole lot of cleanup that needs to happen as well as rewriting the commit message if that works | 20:19 |
| clarkb | but I just want to see if this makes it happier | 20:19 |
| clarkb | if it does I can simplify the pyproject.toml and build meta hooks back down to looking more like they did before I started this expedition | 20:20 |
| clarkb | I think the pip version used by python 2.7 just works because it is using the compat already | 20:21 |
| clarkb | so in theory if we can get the signal through and have pip honor it this should work | 20:21 |
| fungi | and then only apply it when the python version is <3.7 i guess? | 20:24 |
| clarkb | ya exactly | 20:27 |
| clarkb | but that doesn't work in the naive shape | 20:29 |
| fungi | sounds like a good escape hatch, and then setuptools 64.0.0 requires_python>=3.7 anyway, but it might make sense to call that out in its pyproject.toml usage documentation that, due to pip's automatic behaviors, pbr-using projects shouldn't add a pyproject.toml until they drop support for older python versions | 20:30 |
| fungi | (pbr itself is an unfortunate special case of that) | 20:30 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Use pyproject.toml https://review.opendev.org/c/openstack/pbr/+/938331 | 20:31 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 20:31 |
| clarkb | fungi: ++ | 20:31 |
| clarkb | fwiw I think the issue I may have now is that this is in the pip that tox is instantiating and my setenv doesnt' affect that one | 20:31 |
| clarkb | so I'm trying with usedevelop off in the py36 env to see if we get further | 20:31 |
| clarkb | but also I need to eat lunch I'll look at this more later | 20:32 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Use pyproject.toml https://review.opendev.org/c/openstack/pbr/+/938331 | 21:18 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 21:18 |
| clarkb | I suspect that first change will pass now. I think we should probably work through the second change though to make sure the integration testing all works as expected too before committing to this | 21:19 |
| clarkb | fungi: do you know if the py-modules=[] in the pbr pyproject.toml is correct for pbr? I'm worried that if we make a wheel of pbr with that we won't get any code included? | 22:15 |
| clarkb | it works for testing because we have teh source code checked otu and we want it to use the local code which is why I suspect that is there | 22:15 |
| fungi | i think that's telling setuptools what trees to auto-index when building the manifest, which pbr is going to create anyway based off the git file list | 22:18 |
| fungi | by default, setuptools will try to find modules to include on its own | 22:18 |
| fungi | so it should still work, but i suppose you can try to run build in a pbr checkout and then unzip -l the resulting wheel | 22:19 |
| fungi | and tar tf the sdist | 22:19 |
| clarkb | ack thanks for confirming. I think you are right that pbr buidls the list of things via git info and this should still work | 22:20 |
| fungi | basically, py-modules=[] is telling setuptools not to look for files on its own | 22:20 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 22:21 |
| clarkb | I'm working on the integration testing fixups now | 22:21 |
| fungi | it's also a relatively recent setuptools "convenience" behavior, so that setting is telling it to just stick to its old (explicit) behavior | 22:23 |
| clarkb | I suspect that with pbr its a bit of a chicken and egg so by telling setuptools to get out of the way we (pbr) can do our own thing. Then for everyone else they use pbr and it just works (I hope) | 22:25 |
| clarkb | I think this is getting close if we hand wave aroubnd the python3.6 limitations. Then its a matter of coordinating with big users like openstack for a rollout plan that is safe enough | 22:26 |
| fungi | yah, i mean in my prior testing it seemed to | 22:27 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 22:28 |
| opendevreview | Clark Boylan proposed openstack/pbr master: Set up PBR with setuptools and six as dependencies https://review.opendev.org/c/openstack/pbr/+/938332 | 22:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!