I can understand the motivation here, but I’m not sure it would work out in practice. And what bothers me is precisely that - in the enthusiasm for the idea, we don’t look closely enough at the pitfalls, and we standardise something that in the end fails to deliver.
Let’s take it as given for the moment that we do standardise something roughly like the proposal @noirbizarre made (just for the purposes of having something concrete). The first thing we would need is for everyone to start using it. Otherwise, your workflow just becomes “each project, check if it uses standard task scripts - if so, run a command to execute the standard task, otherwise, check what they do use and run that”. Which is basically “check what they use and run that”, just with “standard task scripts” being an extra option.
So let’s assume the new standard is popular enough that everyone uses it. That’s a big expectation (why would stable projects in low-maintenance mode bother?) but we can come back to that.
Now, we have the problem that there will be people who take the simplest possible approach and just set up a “test” task that does “nox -s test” or “tox -e test”. So you still need nox and tox installed. And worse, people will quite likely assume that because they are using a standard, all they have to do is to document “to run the tests, just use the standard test task”. And now you have to work out the dependency on nox for yourself. Which isn’t hard, but wasn’t the point to have to do less work than “read the docs, install what they say and run the command they tell you to run”?
In addition, the project’s requirements for running tests have just increased, from “install nox and run nox -s test” to “install nox and pytask, and run pytask test”. Maybe pytask will be uv, or some other existing tool. But it’s an additional dependency, unless every test runner becomes capable of consuming the new task definitions (and I doubt that, for example, pytest will…)
Having said all of the above, I do actually like the idea of having some form of standardised task definition. I just don’t think we should claim benefits that we can only achieve if the standard is universally adopted.
My fear is that we create a standard which generates external pressure on project maintainers to conform, without offering sufficient benefits to those project maintainers. Similar to the pressure we see to “add typing” without considering whether the project benefits from adding (and maintaining) type annotations.
), and changing a development process is never a benefit to the people who designed the existing process. Those who want to ignore it will continue to ignore it, no matter what tool or process comes up. That isn’t our fault, and we don’t have to refuse to design something else just because some people won’t use it.