Custom build targets (for cleanup) post PEP 518

Wow, I did not know that :clap:
Thanks all the tox maintainers and contributors!

☣️.py would also work, but likely stick with the easier to read version of toxfile.py :joy:

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. :smile:

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 :laughing:

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 :smile: - 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… :man_shrugging:

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.