Given that we set `--parallel=True` in `./.coveragerc` then the following could result
in collecting data from multiple runs when not intended:
$ coverage run ...
$ coverage run ...
$ coverage combine
We may want to include this into the `./tox.ini` configuration too but it will be
somewhat annoying to do that win a way that's compatible with Windows for CI.
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?
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.
I also prefer having a `.PHONY: ...` declaration for each phony target, as is done in
the rest of the `./Makefile`, because it makes is easier when removing or refactoring
targets not to forget to also remove or adjust the `.PHONY: ...` declaration.
This is opinionated, so I understand if community members disagree and I'm happy to back
this out.
It's conventional (and I prefer) to group variables toward the top of the `./Makefile`
so I've done that.
I also prefer separating task-oriented "phony" targets above any "real" targets (whose
recipes create/update actual build artifacts on the filesystem). The task-oriented
targets tend to be a better starting point for any developers approaching the
`./Makefile` to understand where to get started.
AFAIK, prefixing a target with a `.` (aside from the special targets make itself treats
differently) is just to exclude it from being the default target, but the default target
is already defined above this one. Also, it just runs another target which doesn't
exist AFAIKT.
This executes: check-debugging, check-interfaces, check-miscaptures,
find-trailing-spaces, check-umids, pyflakes.
Other changes:
* fix check-umids.py to take starting points. run it as `check-umids.py
src` instead of `check-umids.py src/allmydata/*.py`
* check-debugging: rewrite in python to run from tox: tox doesn't like
to run shell scripts.
* put check-interfaces.py last: it produces lots of warnings, but passes
anyways. The others only produce significant output if they fail.
This replaces the following targets with "echo this is obsolete":
* fetch-and-unpack-deps (used by the old 'tarballs' builder, for SUMO tarballs)
* test-desert-island (used by the old 'clean' builder)
* test-pip-install (used by 'new-pip' builder before we switched)
It also removes the test-pip-install.py helper script.
