Wow, I did not know that 
Thanks all the tox maintainers and contributors!
☣️.py would also work, but likely stick with the easier to read version of toxfile.py 
Is there documentation or examples of toxfile.py?
Can you talk about why you’d prefer a toxfile.py file instead of tox.ini? It feels like moving backward to use an executable file format rather than a declarative format. Like, I’m finally happy to be able to get rid of my setup.py files. 
1 Like
Not at this point and we likely need to add some syntactic sugar like helpers to make it easier, but there’s a plan to add it.
Some people just like reading Python, isn’t that right @pradyunsg 
I my personal workflow, I always end up adding a python -c '...' somewhere to the tox.ini file…
(e.g. python -c 'import shutil; shutil.rmtree("dist", True)', since Python scripts can be platform independent)
Thanks @abravalheri - is that just because there’s a lack of common cleanup semantics in pyproject.toml or related tools? LIke, if you had that, would you still want a toxfile.py? I’m trying to understand the use cases.
Okay, I get that - just to say though that executable files make it really difficult to interoperate with other tools. At least I can parse a .toml file using non-Python tools and consume them into a larger software ecosystem. As much as I wish everything was Python… 
I my personal workflow, I always end up adding a
python -c '...'somewhere to the tox.ini file…
(e.g.python -c 'import shutil; shutil.rmtree("dist", True)', since Python scripts can be platform independent)
I’ll say amen to that. I just replaced some old reports using (no kidding): ksh, sh, bash, expect, perl, sqlplus, and PL/SQL with one tool - django management commands. Someone retired, and the new developer isn’t really UNIX savvy. I have to fix that, but expect and perl at least are no longer needed.
1 Like
That is a good question. I am not 100% sure if this is just because of the lack of support for cleaning up, although that seem to be the most prominent use case.
I think people tend to reach out for python -c in tox.ini to achieve simple tasks that are common when maintaining a package but not easy to implement in a platform-agnostic way (removing/renaming files, creating directories, checking the modification date of a file, displaying messages etc…)
I tend to use command runners for things like “run lint”, “run tests”, “build sdists/wheels”, “clean up”. Pip has nox targets for revendoring dependencies and doing a release.
I don’t think for my use cases, having a “cleanup” command would let me get rid of nox/just/invoke/whatever. And having a PEP 517 “cleanup” hook would probably mean pip needing to gain a pip clean command, which would set up a backend in an isolated environment, etc, just to call the hook. That’s all way more work than I think is warranted, for something that’s typically just rm -r build (for setuptools at least)…
1 Like
FWIW, this was my first thought as well, especially when Nox and its supporters seem to really emphasize its executable format as its primary advantage over Tox. I can see why that could make more sense for a more flexible, execution-oriented task runner as opposed to packaging configuration, though it still feels a bit like a step backwards, relative to mostly relying on a set of standardized building blocks while allowing executable Python code as an escape hatch. But I’m far from an expert on either runner.