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.
The [Patches Trac Wiki page](https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Patches) says
that users should run the `codechecks` tox environment, so this change runs it be
default as the full tox test suite eliminating the extra step.
On systems where the default Python is Python 3 (such as on recent Debian/Ubuntu
versions), then `$ tox -e codechecks` has a ton of failures related to Python 3
compatibility. This explicitly forces it to use Python 2.7 until we have Python 3
compatibility.
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.
