All this is a problem space tox/nox/invoke is addressing directly. So not sure why we need to do anything here. Other than perhaps have a unified configuration for those tools? But at that point why not just add a dev-tool bootstrap before and let each dev tool use their own DSL to define and maintain tasks. In the past when I’ve given pyproject.toml a go with tox my conclusion was that TOML is a very verbose mode to define stuff compared to e.g. an ini file… I don’t think we can really unify configurations for tox/nox/invoke. Last time this came up (a bit over two years ago) the conclusion was that we probably want to standardize a subset of tox, but that would require a clear explanation what/how the frontend (in this case tox/nox/invoke) needs to do.
In my experience adding the virtualenv script path as is to the existing PATH is not enough. Sometimes you want to enforce it must come from there or nowhere else. Also note that the python executable location and the virtual environments scripts location doesn’t always match, so you need to add at least two paths.
Who would use these commands? What are the build/install/environment variable dependencies of those commands?
What is a provider?