It turns out that tox routinely deletes the `./.tox/log/` directory which means it can's
be used for `./Makefile` targets. While this seems like broken or at lease surprising
behavior (I expect logs to be preserved by default), it's easy enough to workaround like
this.
Move the VCS hook installation to a dedicated target to emphasize that it's opt-in.
Document why one might use the hooks and document how to install them.
The VCS hook installation was running when no changes had been made to
`./.pre-commit-config.yaml` because something else had changed the contents of `./.tox/`
resulting in it having a newer modification time stamp. Fix this by using an explicit
log file as the target instead of the directory.
Personally, I can't stand working without a VCS hook anymore. It saves me so much time
in context switches from revisiting and revising PRs when I see that the CI run is red.
Much better to fail before I push so I can revise while the relevant changes are fresh
in my head.
In order to start using this, one has to run `$ make build` first. Should I add that
and make other documentation changes in the wiki related to my changes in this PR?
There's no need in almost all cases to run the tests both under the coverage collector
and without it. This fixes the default set of tests to avoid that. Specifically, don't
run tests under the coverage collector by default for all environments since we don't
capture any error or failure conditions on reporting coverage anyways.
TL;DR: Capture how to use real source file paths for local development.
It can be useful to run the tests against the currently checked out Python source files.
Changes are reflected immediately. Source file paths in Tracebacks (and other things
that print the file path for Python modules) are to the actual checked out source and
can be copied and pasted or used by tools that expect real paths.
OTOH, testing against a real Python package install into a virtualenv done from a real
source distribution can expose rare but very confusing issues.
So doing both is valuable. Most typically, the former is useful for local development
and the latter is most appropriate in CI.
While the XML coverage report is useful for consumption by other tools, such as
currently by codecov.io in CI, it's not very useful for humans reviewing the immediate
impact of changes on coverage during local development or while monitoring CI output. I
don't think running the text report takes much more time so I don't see a downside
here.
