I was wondering when someone would report this...

That's a very conscious design decision 🎓

Rationale

If you are formatting a project for the first time, you don't want isort, black, pyupgrade and what not to modify the code in all sorts of ways. Specially if you are the one having to review that PR 🤦🏾

Instead, by stopping at each formatter, you allow yourself to make:

tox -e format
git add -A
git commit -m"chore: pyupgrade"

tox -e format
git add -A
git commit -m"chore: isort"

tox -e format
git add -A
git commit -m"chore: black"

tox -e format
git add -A
git commit -m"chore: zpretty"

That makes you a great and tidy developer that cares about the others' time to review your PRs ✨

Backdoor 🚪

If you don't care about the above, simply run tox -e lint that will format AND lint the code all in a single step

That's why we have two tox environments (format/lint) so we can use either approach.

I personally, when configuring plone/meta for the first time on a project I use tox -e format and do the proper commits, and afterwards use tox -e lint.

When producing patches, I mostly use directly tox -e lint as the base branch is already ensured to be tox -e format complaint 🤖

Only when doing a major refactoring, I tend to use again tox -e format

Does that make sense? 🤔

At the end, it all depends on what you use in CI... if on CI you already are already running tox -e lint, then you can simply ignore tox -e format. If you only care about tox -e format on CI, then the linting might be too verbose/noisy for you ⚖️

I agree with Gil here.
Also, you can run pre-commit run -a without using tox.

@gforcada I see your points :-)

My use case is not for reformatting but running it after a new package is created with Cookiecutter. It makes no sense to create many commits on a newly created codebase :-)

Of course, in a large codebase, your point is 100% valid during a reformat.

Anyway, let me test running just the lint after the code creation