| *** agalica_ is now known as agalica | 06:15 | |
| cardoe | Do we have a minimum "tox" version that we use for Zuul? | 16:00 |
|---|---|---|
| fungi | it's usually expressed in the tox.minversion field of each project's tox.ini based on the features they rely on | 16:40 |
| fungi | though our zuul jobs try to use the latest available version of tox | 16:40 |
| fungi | based on the way the jobs are written, i think it will effectively use the latest version of tox that is installable with the default python interpreter on the platform where it's run | 16:41 |
| fungi | so for older platforms that could be older tox versions | 16:41 |
| fungi | for example the current latest tox release, 4.53.0, requires python 3.10 or later, so on platforms defaulting to python 3.9 we'd use an older tox version | 16:43 |
| fungi | like ubuntu focal, debian bullseye, or centos 9 stream | 16:45 |
| fungi | the ensure-tox role from zuul-jobs does allow the installed version of tox to be controlled with an `ensure_tox_version` variable, but defaults to installing the latest possible version for the platform where it's run | 16:47 |
| fungi | cardoe: does that ^ answer your question, or were you looking for something else? | 16:47 |
| fungi | maybe the precise answer to your question is that openstack doesn't mandate a minimum tox version in ci jobs, but projects can express one individually and also custom jobs or variants can pin to a specific tox version they want installed | 16:49 |
| cardoe | I'm mostly asking about https://review.opendev.org/c/openstack/nova/+/984918 | 16:50 |
| fungi | ah, context definitely helps with these sorts of questions | 16:50 |
| cardoe | So constraints like stephenfin did is the preferred way for tox to specify these things but that option appeared in 4.28 and newer | 16:50 |
| cardoe | We were talking the other day about the performance of tox vs prek and other stuff. | 16:51 |
| fungi | yeah, its correct to increase the tox.minversion when relying on new syntax to a version that supports that syntax, in my opinion, though i don't think we have a policy about it | 16:53 |
| fungi | per https://pypi.org/project/tox/4.28.0/ that version requires python 3.9, so won't work in py38 jobs on old stable branches | 16:54 |
| fungi | but as long as it doesn't get backported, that's probably fine | 16:54 |
| fungi | e.g. stable/2024.1 requires py38 testing because that's the default on ubuntu focal, according to https://governance.openstack.org/tc/reference/runtimes/2024.1.html | 16:56 |
| cardoe | tox.minversion is deprecated | 16:56 |
| cardoe | They're also doing stuff in newer versions around lock files for the environments. | 16:56 |
| fungi | looks like they recommend setting the minimum tox version in a tool.tox.requires list in your pyproject.toml | 16:57 |
| cardoe | Anyway we'll have these issues when running newer versions of tox with the older deprecated operations. | 16:58 |
| cardoe | Interestingly the fixes in newer tox versions are all written / contributed by openstack folks. | 16:58 |
| fungi | neat. since opendev's projects moved off tox after v3, my familiarity with its conventions has waned significantly, so this is all news to me | 16:59 |
| cardoe | https://github.com/tox-dev/tox/issues/3553 is the minversion / requires thing you mentioned | 16:59 |
| cardoe | What'd you replace tox with? | 16:59 |
| fungi | nox | 16:59 |
| fungi | it gets configured with a nox.py file, native python syntax | 17:00 |
| cardoe | oh I've been using pyproject.toml based methods. | 17:01 |
| fungi | the overloading of pyproject.toml files for purposes beyond packaging has become increasingly problematic, it seems like ever tool author decided to cram their options in there and then deprecate their own config files | 17:02 |
| fungi | it's about to get even more fun since the toml spec continues to evolve and the cpython stdlib's toml parser now supports different syntax depending on what python version you're running, so we're likely to start running into new pyproject.toml files that can't even be parsed on earlier python interpreters | 17:04 |
| stephenfin | fungi: I thought they'd decided against supporting TOML 1.1 yet? (for exactly that reason) | 17:20 |
| stephenfin | cardoe: I knew `minversion` (or `min_version`) was deprecated, but it was less of lift to bump that than to rework to use `requires` | 17:20 |
| stephenfin | (I think I may have even written the docs update to note the deprecation) | 17:21 |
| cardoe | pyproject.toml was always meant for more than packaging though so I don’t have an issue with using it. | 17:21 |
| cardoe | stephenfin: you did | 17:21 |
| fungi | stephenfin: they waffled back and forth, but last i saw the cpython maintainers had accepted toml 1.1 support for cpython 3.15 | 17:21 |
| fungi | as in merged the pr | 17:22 |
| fungi | https://docs.python.org/3.15/library/tomllib.html | 17:22 |
| fungi | "This module provides an interface for parsing TOML 1.1.0 ..." | 17:22 |
| stephenfin | interesting. you'd hope they'll provide a backports lib (or straight up do a backport) for older versions but they don't seem to bother with backwards compat anymore | 17:23 |
| fungi | the upshot of the conversation on discuss.python.org was that projects will just have to be careful to avoid toml 1.1 syntax in pyproject.toml files if they want their sdists to be buildable on python prior to 3.15 | 17:23 |
| fungi | (or with build-backends in other languages that lack toml 1.1 support) | 17:24 |
| stephenfin | Good point. The backport is less of a requirement actually. | 17:24 |
| fungi | i think the winning argument was that pre-toml-1.0 the stdlib tomllib had already existed and nobody made a stink when it upgraded to add support for toml 1.0, so why should 1.1 be any different? | 17:26 |
| cardoe | I mean same argument can be made for setup.py or nox.py if you use newer python syntax | 17:26 |
| fungi | yes | 17:26 |
| fungi | for our own pyproject.toml files i don't expect we'll have any problem because we require openstack projects to test with a minimum python version | 17:28 |
| fungi | where it might get hairy is if one of our dependencies that ships only sdists (those are becoming rare at least) uses toml 1.1 syntax in their pyproject.toml file and doesn't simultaneously add `requires_python>=3.15` | 17:29 |
| fungi | so maybe not likely | 17:30 |
| cardoe | fungi: our dependencies are the latest and newest code from 2009. | 18:36 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!