| opendevreview | Merged openstack/pbr master: Set setuptools min in requirements.txt https://review.opendev.org/c/openstack/pbr/+/1002140 | 02:16 |
|---|---|---|
| bbezak | Hi. We’re ready to make a release now as patch above merged ? | 06:20 |
| bbezak | (Pbr) | 06:20 |
| mnasiadka | stephenfin: can you help with ^^? | 08:09 |
| stephenfin | mnasiadka: https://review.opendev.org/c/openstack/releases/+/1002264 | 11:48 |
| mnasiadka | Ah, I was not aware pbr is tracked in releases eepo | 12:00 |
| frickler | stephenfin: fungi: the tomli thing is still failing with 7.1.2: https://zuul.opendev.org/t/openstack/build/af09bd0a1c5a45069edf0f97d55cef09 :( | 12:51 |
| frickler | maybe we should pull both 7.1.1 and 7.1.2 at this point? | 12:52 |
| stephenfin | I'm trying and failing to reproduce that locally :( | 13:23 |
| opendevreview | Stephen Finucane proposed openstack/pbr master: Duplicate check for tomli dependency https://review.opendev.org/c/openstack/pbr/+/1002286 | 13:31 |
| opendevreview | Stephen Finucane proposed openstack/pbr master: Add tomli as dependency on Python 3.7 - 3.10 https://review.opendev.org/c/openstack/pbr/+/1002287 | 13:31 |
| frickler | stephenfin: would it help if I hold a CI node for you to access? | 13:31 |
| stephenfin | frickler: The issue with just yanking is that it doesn't help us progress | 13:34 |
| bbezak | python3.10 -m venv /tmp/v && /tmp/v/bin/pip install -q pbr==7.1.1 setuptools==59.6.0 && /tmp/v/bin/python -c "import setuptools.dist as d; d.Distribution({'name':'test'})" | 13:34 |
| bbezak | Tested on laptop | 13:35 |
| stephenfin | bbezak++ thank you 🙏 So the version of setuptools is too old, not too new 😅 | 13:35 |
| frickler | stephenfin: I didn't say "just yanking", I'm all for providing a fixed 7.1.3 asap, but does it help you or anyone to keep 7.1.1 and 7.1.2 around until then? | 13:36 |
| stephenfin | Yes that would make sense. Sorry I misunderstood what you were suggesting | 13:38 |
| bbezak | And to reproduce it for 7.1.2 one needs to work on the repo https://paste.opendev.org/show/bIULVCgqsSGthc4eyhSP/ | 13:46 |
| fungi | i can yank both new versions for now | 14:03 |
| fungi | once i can get to the e-mail to log into the pypi account, because after username+password+2fa it also wants to send a confirmation token by e-mail | 14:08 |
| fungi | they've gone way overboard with their authentication roadblocks | 14:09 |
| bbezak | I can see we’re on 7.0.3 now, thx | 14:17 |
| fungi | yes, all done | 14:19 |
| opendevreview | Adam Harwell proposed openstack/tooz master: Add Consul coordination driver using native services https://review.opendev.org/c/openstack/tooz/+/997145 | 14:58 |
| opendevreview | Adam Harwell proposed openstack/oslo.messaging master: HTTP-RPC driver: core transport, server, and dedup https://review.opendev.org/c/openstack/oslo.messaging/+/997470 | 14:58 |
| opendevreview | Adam Harwell proposed openstack/oslo.messaging master: HTTP-RPC driver: tooz service discovery and fanout broadcaster https://review.opendev.org/c/openstack/oslo.messaging/+/997471 | 14:58 |
| opendevreview | Adam Harwell proposed openstack/oslo.messaging master: HTTP-RPC driver: DevStack plugin, CI jobs, and documentation https://review.opendev.org/c/openstack/oslo.messaging/+/997472 | 14:58 |
| stephenfin | fungi: clarkb: I'm not really sure how to proceed with the pbr stuff /o\ | 15:04 |
| stephenfin | https://review.opendev.org/c/openstack/pbr/+/1002286 should fix the main issue seen in kolla but while testing I'm seeing a new issue: | 15:04 |
| stephenfin | ModuleNotFoundError: No module named 'setuptools.command.build' | 15:04 |
| stephenfin | I dug around long enough without getting anywhere before deciding to pull in an LLM, which gave me the following https://paste.opendev.org/show/bStAmqTzyBQw9bxDSuNn/ | 15:05 |
| stephenfin | I'm still verifying that but the reasoning checks out superficially at least. That means the fix in 7.1.2 is fixing stuff in one environment while breaking it elsewhere | 15:06 |
| clarkb | the pre summer release of pbr works right? | 15:07 |
| clarkb | and that builds things? | 15:07 |
| fungi | yes, 7.0.3 | 15:07 |
| clarkb | ok so the problem is in PBR itself not the environment changing around us | 15:08 |
| fungi | it just requires all packages to have a setup.py file activating pbr and setup.cfg file declaring the package name | 15:08 |
| clarkb | I just wanted ot make sure that setuptools hasn't also updated in a way that is creating problems for us | 15:08 |
| fungi | so goes through different (potentiallt deprecated in some places) parts of setuptools | 15:08 |
| stephenfin | no, the issue is that the matrix of possible package combos and installer mechanisms is very large, and I have no good way to test against all of them | 15:09 |
| stephenfin | I don't even know many of the combos exist/are possible until we push a release out and someone complains 😅 | 15:09 |
| stephenfin | unknown unknowns and all that | 15:10 |
| clarkb | stephenfin: right so the approach we've used to avoid problems like this historically has been to be very careful about what things we require in PBR and what things we drop support for etc | 15:10 |
| clarkb | we've sort of had this conversation before but you're taking a very different approach to PBR maintenance than the one fungi and I have applied for years whcih si fine but is far more prone to these problems | 15:10 |
| clarkb | maybe we can reset the approach and make it much more opt in based on known factors. eg you have a pyproject.toml otherwise don't even process things with this new code path | 15:11 |
| clarkb | if we want to do major refactors of the entire code base holistically and drop support for features then we probably need to start with more robust testing? | 15:12 |
| clarkb | If 7.0.3 works today then I think going down one of those two paths is what I would do. (Figure out testing to make big refactors less error prone or resume small incremental changes that drop drop support for features or add hard requirements on new ones) | 15:13 |
| stephenfin | the only thing we removed in 7.1.x is dead code and testing for Jammy (due to infra issues moreso than anything) | 15:14 |
| stephenfin | and pyproject.toml file check already exists | 15:14 |
| clarkb | stephenfin: if the pyproject.toml file checkl exists why were we unconditionally importing tomli and failing in stable branches that don't do anything with toml? | 15:14 |
| clarkb | (that was the original break aiui) | 15:15 |
| clarkb | I haven't seen the new failure yet so haven't looked into it beyond skimming the notes above | 15:15 |
| stephenfin | because it's registered via an entry point | 15:15 |
| stephenfin | and unlike Python code, we can't make the entry point conditional on Python/setuptools versions | 15:16 |
| clarkb | right, the entry point itself would have to guard against this stuff / dispatch the correct underlying routines bsaed on the package setup (and I guess the platform itself) | 15:17 |
| stephenfin | exactly | 15:17 |
| fungi | clarkb: unfortunately the "you have a pyproject.toml" test is also potentially misleading since a lot of tools have recently co-opted it as a registry to combine all their configuration, so people may stick tool settings in one even if their packaging is still via other methods | 15:18 |
| clarkb | I should note a third approach that may be worth considering (but potentially problematic for end users) is forking pbr into legacy and modern pbr libraries | 15:18 |
| clarkb | fungi: we could just say that is unsupported by pbr | 15:19 |
| clarkb | either you use pyproject.toml for packaging and everything else or you don't use it at all | 15:19 |
| fungi | i agree, we can take that angle, for sure | 15:19 |
| clarkb | I think for openstack there are unlikely many cases of that situation | 15:19 |
| stephenfin | clarkb: I'm leaning that way too now | 15:19 |
| stephenfin | if we only had to care about pip, it would be likely be far more manageable, but the old easy_install stuff is a debugging nightmare | 15:21 |
| clarkb | stephenfin: the upside to forking is we can set a new baseline of supported functionality in the modern version. Then theoretically the difficult to modify legacy stuff can sit as is with minimal updates | 15:21 |
| clarkb | stephenfin: do you haev a link to the new build command error? | 15:21 |
| stephenfin | sure. I'm working on bbezak's reproducer from above. repasting: | 15:22 |
| stephenfin | https://paste.opendev.org/show/bIULVCgqsSGthc4eyhSP/ | 15:22 |
| clarkb | reading well I'm less interested in the artifical reproducer. I'm curious to know where this hapepns in reality | 15:23 |
| clarkb | (in particular it is relatively trivial to install random setuptools versions that a broken/bad and find they don't work with $version of PBR) | 15:23 |
| stephenfin | if you run that you'll get this exception https://paste.opendev.org/show/bZqgf6gNJkoZiCVUfKWi/ | 15:23 |
| clarkb | but what we should be avoiding is breaking PBR with setuptools on various distros and latest versions that run on python 3.8 etc | 15:23 |
| stephenfin | the setuptools version in that reproducer is the version that ubuntu 22.04 shipped with | 15:24 |
| stephenfin | so it's an genuine issue | 15:25 |
| clarkb | ack that is the context I was missing thanks | 15:25 |
| clarkb | so that shows it failign to import tomli | 15:26 |
| clarkb | kolla has a pyproject.toml | 15:26 |
| clarkb | so it is correct for pbr to try and process the toml file and import tomli. But that version of setuptools does not include tomli? If that is the case then kolla simply doesn't support that platform imo | 15:27 |
| clarkb | I don't think PBR needs to add support where there never was support | 15:27 |
| clarkb | it only needs to support things where the support was there. I'm failing at english but hopefully that makes sense | 15:27 |
| clarkb | but lets see maybe that version of setuptools has tomli in a different location? | 15:28 |
| stephenfin | Yep. I knew setuptools.extern.tomli was removed in v71.0.0 but I'd ignored that since that requires Python 3.8 and by Python 3.8 we already had PEP-517 and all the build isolation stuff | 15:28 |
| stephenfin | but it turns out it was only added in v61.0.0 which is obviously > v59.60 | 15:29 |
| stephenfin | *59.6.0 | 15:29 |
| clarkb | stephenfin: oh actually I think thee may be a bug here. The failing command is `setup.py egg_info` that is a legacy command and shouldn't touch pyproject.toml at all right? | 15:29 |
| clarkb | anyway I think the main issue is that kolla is attempting to use pyproject.toml packaging with a platform that never supported pyproject.toml packaging and pbr shouldn't be responsible for backporting that functionality | 15:30 |
| clarkb | kolla needs to upgrade their platform to get working pyproject.toml support | 15:30 |
| stephenfin | right, it shouldn't | 15:30 |
| clarkb | or use legacy packaging? | 15:30 |
| clarkb | then separately there may be a smaller bug that involves PBR trying to do pyproject.toml things when executing setup.py directly | 15:31 |
| stephenfin | but it also shouldn't be loading the `setuptools.finalize_distribution_options` entrypoints (which I believe is how that code is being loaded and executed) pbr.pbr entrpoint | 15:31 |
| clarkb | but in this case that is just an easy way to expose the issue kolla is hitting when they try to pip install | 15:31 |
| stephenfin | *via the pbr.pbr entry | 15:31 |
| stephenfin | my currently plan is to do the following | 15:32 |
| stephenfin | a) revert https://review.opendev.org/c/openstack/pbr/+/1002140 since it apparently breaks easy_install (per the initial LLM report I provided) and instead guard the PEP-660 hook points with setuptools versions checks | 15:34 |
| stephenfin | (TODO: figure out how to do the version checks, since I can't rely on packaging or importlib.metadata or setuptools not removing a __version__ marker (if they haven't done so already) | 15:34 |
| stephenfin | ) | 15:34 |
| clarkb | oh I didn't realize we were doing anything with requirements.txt | 15:35 |
| clarkb | sorry I was halfway around the pacific when most of this stuff got updated and then asleep when things broke and still haven't fully caught up | 15:35 |
| stephenfin | b) proceed with https://review.opendev.org/c/openstack/pbr/+/1002286 and hope that returning early from that function is enough to avoid any other calls into the pyprojecttoml.py file | 15:36 |
| clarkb | stephenfin: what is the expected source of tomli in newer setuptools? Is it just part of python stdlib now or something? | 15:37 |
| stephenfin | They vendor it before Python 3.11. From 3.11 they use tomllib from the stdlib | 15:37 |
| clarkb | there is both a python version check and a setuptools check in that diff. And they imply that tomli is magically available in newer things and setuptools vendors it in older things | 15:38 |
| clarkb | aha got it thanks | 15:38 |
| clarkb | stephenfin: fwiw the docstring on that method implies that this will help since setuptools is running every finalize_distribution_options method which in theory means some compatibiltiy layer/legacy version will run if ours doesnt't? | 15:39 |
| clarkb | all that to say I agree that your plan should improve things. Maybe we want a stronger notice/comment in the requirements.txt file about how this cannot be used to upgrade setuptools only include it? | 15:39 |
| stephenfin | that's my thinking yes, but I suspect we may be the first people to have tried this path 😇 | 15:40 |
| clarkb | *cannot be used to reliably upgrade setuptools. | 15:40 |
| clarkb | as a funny side note: if they had chosen json or ini then most of these specific problems would simply not exist | 15:41 |
| clarkb | we'd probably have more exciting different problems, but the decision to use a new serialization format with poor support in stdlib seems to have created this specific set of problems | 15:42 |
| fungi | or rather the rush to depend on it prematurely in various tooling | 15:44 |
| fungi | people are no longer content to add something to the stdlib and then wait 10 years to say it's safe to assume | 15:44 |
| fungi | it seems like a culture of instant gratification has started to consume the python ecosystem overall | 15:45 |
| clarkb | fwiw I'm not sure that https://review.opendev.org/c/openstack/pbr/+/1002287 will do what is expected of it for the same reason that old setuptools doesn't upgrade to new setuptools | 15:46 |
| clarkb | however, that should only happen in the "legacy" path and if we're skipping this method entirely along that path then maybe it is ok | 15:46 |
| clarkb | I'll leave a comment real quick once I can get my thoughts together | 15:47 |
| stephenfin | sorry, I think https://review.opendev.org/c/openstack/pbr/+/1002287 isn't needed. I've abandoned it. | 15:47 |
| stephenfin | *I now think | 15:47 |
| stephenfin | We need to avoid loading anything to do with pyproject.toml parsing unless we can be sure we can support it | 15:48 |
| clarkb | ack no need for a comment then | 15:48 |
| clarkb | stephenfin: ya I think if we simply avoid that path unless it is supported by the platform then we should be ok (and that means toml parsing would be available) | 15:49 |
| clarkb | stephenfin: and the rough criteria for that are setuptools>=64.0.0 and pyproject.toml file present in the package repo? (I'm mostly thinking ahead to what documentation updates may be needed too) | 15:51 |
| fungi | we already have that requirement somewhat documented | 15:52 |
| clarkb | I guess python3.7 or newer as well | 15:52 |
| clarkb | but importantly PBR can't be expected to magic a working environment. You either start with one or have the build-system requires in pyproject.toml handle it for you | 15:53 |
| clarkb | which is maybe not super well documented? I'm not sure | 15:53 |
| clarkb | I need to head out on the school run now. One last thought before I go: for testing maybe we try to add a test job/framework that has a small number of representative packages and it cross multiplies them against specific python versions using pyenv or whatever and specific setuptools versions | 15:56 |
| clarkb | there is something along these lines in the unittests just with setuptools versions but I think the stdlib stuff matters here based on these results | 15:56 |
| clarkb | so have a job that iterates through python3.7 + setuptools foo and bar then 3.8 etc | 15:56 |
| clarkb | or different jobs for each. But if we keep the representative set of packages small that should give us good coverage while making debugging not terrible | 15:56 |
| frickler | kolla stable/2025.1 doesn't have pyproject.toml. so not sure what they (we) were doing wrong there? | 16:02 |
| opendevreview | Takashi Kajinami proposed openstack/tooz master: Use etcd from distribution https://review.opendev.org/c/openstack/tooz/+/997919 | 16:14 |
| clarkb | frickler: oh yup I missed the branch selection in the git clone earlier | 16:37 |
| clarkb | frickler: so I think the only issue is that pyproject.toml code was running when it shouldn't have. https://review.opendev.org/c/openstack/pbr/+/1002286 should hopefully fix that path | 16:38 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.db master: Add job to run tests with real database backends https://review.opendev.org/c/openstack/oslo.db/+/1002350 | 16:44 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.db master: Drop test with invalid flush_on_nested option https://review.opendev.org/c/openstack/oslo.db/+/1002352 | 16:48 |
| stephenfin | clarkb: I'm wondering if we could simplify https://review.opendev.org/c/openstack/pbr/+/1002286 to check for Python 3.11 and skip everything if not present? 🤔 | 17:00 |
| stephenfin | my rationale being that OpenStack only supports Python 3.11 or later, so we can insist that anyone going down the pyproject.toml-only route must also drop support for Python 3.10 or earlier (which they should already have done) | 17:02 |
| stephenfin | things like git-review will need to keep their setup.cfg / setup.py files but I think that's okay | 17:03 |
| cardoe | So then pbr supports Python 2.6/2.7 and then 3.11+? | 17:03 |
| clarkb | more things than just git review use pbr though | 17:04 |
| clarkb | I think ansible does too? or maybe some specific ansible packages? | 17:04 |
| clarkb | cardoe: the new releases of PBR are attempting to drop python older than 3.7 iirc | 17:04 |
| stephenfin | no, it continues to support all versions. You just need to keep setup.cfg / setup.py around if you want to support Python < 3.11 | 17:04 |
| stephenfin | clarkb: also no: mordred figured a way around that. We're still testing on 2.7 | 17:05 |
| clarkb | stephenfin: we also have to think about projects that are on new python without pyproject.toml but those should be trivially supported since we're just failing on imports | 17:05 |
| clarkb | stephenfin: oh ok | 17:05 |
| cardoe | oh I think that makes sense | 17:05 |
| clarkb | stephenfin: what is the oldest version of python that setuptools 64 supports? (I don't know that we need to align but we're already requiring that for pyproject.toml support so maybe that is informative) | 17:05 |
| stephenfin | python 3.7 https://pypi.org/project/setuptools/64.0.0/ | 17:06 |
| stephenfin | but as I noted earlier, those old versions of setuptools vendor tomli | 17:07 |
| stephenfin | (in fact current versions still do for Python 3.10 support) | 17:07 |
| stephenfin | I don't think we want to go down that path? | 17:07 |
| clarkb | I'm mostly wondering if it is worth supporting pyproject.toml where setuptools can support it (down to 3.7 I guess) | 17:10 |
| clarkb | but I guess not doing that simplifies things and the only projects I can think of that might have issues are those you already mentioned and they can use the old packaging | 17:11 |
| stephenfin | If we do that, we need to figure out how to get toml support in there | 17:20 |
| stephenfin | the current tomli fallback only works on certain setuptools versions or requires users pre-install that package themselves | 17:21 |
| opendevreview | Stephen Finucane proposed openstack/pbr master: Revert "Set setuptools min in requirements.txt" https://review.opendev.org/c/openstack/pbr/+/1002355 | 17:25 |
| opendevreview | Stephen Finucane proposed openstack/pbr master: Only provide PEP-660 entry points on setuptools >= 64.0.0 https://review.opendev.org/c/openstack/pbr/+/1002356 | 17:25 |
| opendevreview | Stephen Finucane proposed openstack/pbr master: Insist on Python 3.11 for pyproject.toml-only projects https://review.opendev.org/c/openstack/pbr/+/1002357 | 17:25 |
| stephenfin | clarkb: fungi: ☝️ | 17:25 |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 17:27 |
| clarkb | and that is a half sketched out "what woudl it look like to try and create test scenarios that explode the python, setuptools, pip, etc matrix | 17:28 |
| stephenfin | nice | 17:29 |
| clarkb | I sort of left the hard part out (which is managing isolated envs for setuptools/pip versions), but for a first pass of do we even want to pursue this I think it shows the rough idea | 17:32 |
| fungi | i'll note that if we go that route, it will probably be a long time until we can drop the setup.cfg and setup.py from bindep, which had been my test case for pbr's pyproject.toml support | 17:33 |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 17:38 |
| clarkb | fungi: https://zuul.opendev.org/t/openstack/build/4ccfd1c0525c489e906874c6c4b22263 this is hitting the pbr changes from stephenfin any idea why that package is not aroudn anymore? | 17:46 |
| clarkb | specifically `E: Unable to locate package ksmtuned` from apt-get | 17:46 |
| fungi | looks like that build was on ubuntu-noble | 17:48 |
| fungi | https://packages.ubuntu.com/ksmtuned claims it's included on noble | 17:48 |
| fungi | https://zuul.opendev.org/t/openstack/build/4d2c1ce338d54931be188b0f13ec5da4/ has an apt update failure | 17:50 |
| fungi | maybe one of our mirror servers is broken? | 17:50 |
| clarkb | they both ran in rax flex dfw3 so ya maybe | 17:51 |
| clarkb | also is it weird that the devstack issue didn't fail on the ap-tget update? | 17:51 |
| tkajinam | I suspect devstack does not set +e | 17:57 |
| tkajinam | and no explicit return code check is implemented in its install_package func | 17:57 |
| tkajinam | I found a few job failures caused by unstable mirror so yeah I suspect that. ex. https://review.opendev.org/c/openstack/python-glanceclient/+/999283/comments/ca93c0ae_761ff873 | 17:58 |
| * tkajinam noticed the same is being discussed in matrix | 18:01 | |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 18:28 |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 21:24 |
| clarkb | fungi: stephenfin ^ the biggest gotcha I've run into doing that has to do with build isolation in pip and build. In particular we want to test using PBR in a speculative state. So I have a whole install PBR into the venv step from the zuul checkout. Then use no build isolation flags. Thats fine except that if a package has extra build depends other than setuptools and pbr we | 21:25 |
| clarkb | won't be handling those cases | 21:26 |
| clarkb | I'm wondering if anyone knows of a good way to modify these isolated builds specifically to test libs like pbr. I mean setuptools and flit etc must have a solution to this? Or maybe they are just doing what I'm doing and not testing with isolation when they want to test themselves | 21:26 |
| clarkb | anyway I don't think that is a huge deal because PBR implies setuptools (for now anwyay) and I am not aware of any projects with additional build deps | 21:27 |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 21:31 |
| fungi | i really don't know since i've not closely observed the development process in those projects | 21:34 |
| clarkb | ya the docs don't seem to give any clues, but maybe if I dig into their test frameworks something will pop up | 21:35 |
| clarkb | anyway I think if we ignore that problem then for any given python version we can curate a set of scenarios against real packages using various setuptools and pip versions | 21:36 |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 21:49 |
| clarkb | ok I think that is working now. Its not super different from the existing testingthat we have. I think what sets it apart is that its very explicitly controlling the python, setuptools, and pip versions where we try to run tests on platforms we care about and jsut accept what they give us in other jobs | 22:05 |
| clarkb | if we think this is valuable I can clean it up and we can work on a list of scenarios. I do think what this gives us for the future is the ability to say "X broke after this release" capture that as a new scenario and ensure that it does fail then test against that | 22:05 |
| clarkb | which is more difficutl with the existing test jobs | 22:05 |
| clarkb | basically I'm hopeful that this gives us a way to capture an ongoing set of regression corner cases and ensure they are happy going forward | 22:06 |
| clarkb | though the test case for jammy with setuptools 59.6.0 succeeded and I'm not basing this on top of the fixes so maybe we need extra installation checks? Currently it uses build to make an sdist, make a wheel, and then does a pip install | 22:11 |
| clarkb | I see the problem. Installing build installs tomli which amkes it work | 22:12 |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 22:16 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.log master: Remove duplicated optional dependencies from test requirements https://review.opendev.org/c/openstack/oslo.log/+/1002002 | 22:37 |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 22:42 |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 23:08 |
| opendevreview | Clark Boylan proposed openstack/pbr master: WIP Sketch out a more generic integration test for PBR https://review.opendev.org/c/openstack/pbr/+/1002358 | 23:23 |
| clarkb | fungi: stephenfin it is interesting how many tools end up relying on other tools without explicit dependencies even with the modern toolchains. Like pip needs wheel installed to build a wheel and will apparently fail in some situations if it can't do that | 23:24 |
| clarkb | separately build pulls in tomli making all these problems go away | 23:24 |
| clarkb | its amazing any of this ever works from one computer to another | 23:24 |
| fungi | yes, also all of them at one point or another work around those problems by just vendoring in copies of some of their dependencies | 23:43 |
| opendevreview | Merged openstack/oslo.db master: Do not install code to build release notes https://review.opendev.org/c/openstack/oslo.db/+/1002180 | 23:55 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!