Historically, this is the spot where I would have mentioned and recommended tox, but at the moment I’m exploring alternatives to it, such as nox, and as a result I don’t currently have a specific recommendation for such a tool.
This isn’t being down on tox. It’s just that there’s a plausible alternative in the form of nox.
I’ve been using it for years. Just for a variety of reasons I’m currently looking at what else is out there. Currently focused on seeing what I can get out of nox. I was expecting not to like the config-via-Python-file approach, and I’m still on the fence about it, but there are other things about it that I’m liking.
For example, I run CI for all my personal open-source stuff on GitHub Actions, and my approach is to run the test suite against every supported Python version, but the other checks – linters, documentation, packaging, etc. – only against the latest Python I’m supporting (which will be 3.11 for the wave of updates I’m working on right now). So I have a bunch of environments that I only want to run on 3.11. With tox, the Python version is not a first-class selector, which is why all the tox CI plugins I’ve ever used require declaring a duplicate mapping of testenvs to Python versions so they can figure out which ones to select/deselect. But in nox, the Python version is a first-class selector, which means I don’t even need a plugin. I literally have a GH Actions workflow with nox that just does python -Im nox --non-interactive --python ${{ matrix.python-version }} and it works, because each nox session already declares which Python(s) it should run with.
On the other hand, the fact that nox uses the "list", "--of", "arguments", "-style" gets really unwieldy for some of the longer command lines. So I don’t know if I’m going to commit to it long-term. But I’m at least enjoying learning a bit about it.
As my other comment points out, I’ve historically used tox for my one open-source projects, but I’m currently exploring other options.
I’ve used plenty of other things at various jobs, and generally go with “whatever the team likes best”. For the team I currently work with, that’s Dockerizing everything, with a Makefile to drive it.
You can use tox to automate any task you like, really. It has a lot of testing-oriented features because that’s a lot of what people want to automate, but it isn’t limited only to testing.
For my projects that have used tox, I don’t have automated “deploy” because the “deploy” is publishing a new version of the package to the Python Package Index, and A) I always want to decide when and whether to do that, and B) am not going to hand over my PyPI API token to any CI tool, because that could cause some havoc if the CI tool ever gets breached.
At work, our deployments are set up in the CI/CD tool using its configuration mechanism. Local dev tasks are all driven by the Makefile.
Why are you down on tox lately?
This isn’t being down on tox. It’s just that there’s a plausible alternative in the form of nox.
I’ve been using it for years. Just for a variety of reasons I’m currently looking at what else is out there. Currently focused on seeing what I can get out of
nox. I was expecting not to like the config-via-Python-file approach, and I’m still on the fence about it, but there are other things about it that I’m liking.For example, I run CI for all my personal open-source stuff on GitHub Actions, and my approach is to run the test suite against every supported Python version, but the other checks – linters, documentation, packaging, etc. – only against the latest Python I’m supporting (which will be 3.11 for the wave of updates I’m working on right now). So I have a bunch of environments that I only want to run on 3.11. With
tox, the Python version is not a first-class selector, which is why all thetoxCI plugins I’ve ever used require declaring a duplicate mapping of testenvs to Python versions so they can figure out which ones to select/deselect. But innox, the Python version is a first-class selector, which means I don’t even need a plugin. I literally have a GH Actions workflow withnoxthat just doespython -Im nox --non-interactive --python ${{ matrix.python-version }}and it works, because eachnoxsession already declares which Python(s) it should run with.On the other hand, the fact that
noxuses the"list", "--of", "arguments", "-style"gets really unwieldy for some of the longer command lines. So I don’t know if I’m going to commit to it long-term. But I’m at least enjoying learning a bit about it.Do you have any thoughts on command runners? E.g., do you like to use Makefiles, Justfiles, Invoke, or just run the commands raw?
As my other comment points out, I’ve historically used
toxfor my one open-source projects, but I’m currently exploring other options.I’ve used plenty of other things at various jobs, and generally go with “whatever the team likes best”. For the team I currently work with, that’s Dockerizing everything, with a
Makefileto drive it.I thought tox was more oriented around testing. Does it also allow you to run commands for deployments or other project related tasks?
You can use
toxto automate any task you like, really. It has a lot of testing-oriented features because that’s a lot of what people want to automate, but it isn’t limited only to testing.For my projects that have used
tox, I don’t have automated “deploy” because the “deploy” is publishing a new version of the package to the Python Package Index, and A) I always want to decide when and whether to do that, and B) am not going to hand over my PyPI API token to any CI tool, because that could cause some havoc if the CI tool ever gets breached.At work, our deployments are set up in the CI/CD tool using its configuration mechanism. Local dev tasks are all driven by the
Makefile.