One thing I’ve really begun to like since figuring it out: in nox, Python version is a first-class selector.
In tox, you can associate a given testenv with a particular Python version by declaring the basepython key for that testenv. And you can build a matrix of Python versions with the generative features. But there’s no easy way to runtox and say “only run the testenvs that go with this Python version”. You can select on lots of things, but not Python version. Which means that for CI systems which tend to run each Python version as its own job/container, you end up needing a plugin that will selectively enable the correct testenvs based on Python version. I used to use tox-travis for this, and then tox-gh-actions when I switched to GitHub Actions CI. But doing this always required duplicating information: you need to specify your testenv/python-version matrix all over again for the plugin so that it knows which envs go with which Python versions.
Meanwhile in nox, you declare the associated Python version(s) for a given session in the nox.session decorator, and then can run nox --python <version> to select only sessions associated with <version>. This means you don’t need any kind of duplicate mapping or even a plugin; as long as the active Python version is available as a variable in the CI config you can pass it as a command-line argument to nox and run only the correct sessions for that version.
With the one exception of pre-releases (that matters only to the 0.1%) which I’ve hilariously opened a bug about just yesterday: https://github.com/wntrblm/nox/issues/685
I could probably write some extractor with regexp-fu but debugging CI is a nightmare.
I’m glad I read this. I’ll probably migrate everything of mine to nox. I’ve been using tox so far and it’s been one of the few “I don’t get it, but it’s so weird I don’t care to learn properly” tools. And that’s a really high threshold to reach for me since I love esoteric things.
One thing I’ve really begun to like since figuring it out: in
nox, Python version is a first-class selector.In
tox, you can associate a given testenv with a particular Python version by declaring thebasepythonkey for that testenv. And you can build a matrix of Python versions with the generative features. But there’s no easy way to runtoxand say “only run the testenvs that go with this Python version”. You can select on lots of things, but not Python version. Which means that for CI systems which tend to run each Python version as its own job/container, you end up needing a plugin that will selectively enable the correct testenvs based on Python version. I used to usetox-travisfor this, and thentox-gh-actionswhen I switched to GitHub Actions CI. But doing this always required duplicating information: you need to specify your testenv/python-version matrix all over again for the plugin so that it knows which envs go with which Python versions.Meanwhile in
nox, you declare the associated Python version(s) for a given session in thenox.sessiondecorator, and then can runnox --python <version>to select only sessions associated with<version>. This means you don’t need any kind of duplicate mapping or even a plugin; as long as the active Python version is available as a variable in the CI config you can pass it as a command-line argument tonoxand run only the correct sessions for that version.With the one exception of pre-releases (that matters only to the 0.1%) which I’ve hilariously opened a bug about just yesterday: https://github.com/wntrblm/nox/issues/685
I could probably write some extractor with regexp-fu but debugging CI is a nightmare.
edit: I’ve figured it out with a bit of bash-fu: https://github.com/hynek/environ-config/pull/48/files
edit 2: I’ve updated the post re: this topic
I’m glad I read this. I’ll probably migrate everything of mine to nox. I’ve been using tox so far and it’s been one of the few “I don’t get it, but it’s so weird I don’t care to learn properly” tools. And that’s a really high threshold to reach for me since I love esoteric things.