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.
This is needed to allow virtualenv-based builds to exercise
test_runner.BinTahoe (and a few others), which expect to run an
executable program in "bin/tahoe". This also helps users who aren't yet
accustomed to the new virtualenv world where they can just run "tahoe"
instead of "bin/tahoe".
This changes the "setup.py make_executable" command to copy the first
"tahoe" executable found on $PATH into bin/tahoe . Previously bin/tahoe
was created by modifying the shbang line of a template stored in
bin/tahoe-script.template (which has been deleted).
It also changes setup.cfg to run "make_executable" before tests,
and *after* an install. Note that you must use "setup.py install" before
"setup.py test", since make_executable requires the installed "tahoe" on
$PATH.
In the future, we hope to get rid of bin/tahoe altogether, and have
these tests run the "tahoe" from $PATH directly.
So use 'tox -e check-memory' instead of 'make check-memory'. The tox
version will create a virtualenv and install tahoe for you before
running the tests, removing one use of the 'tahoe @FILENAME' hack (which
was used to run a python file with a PYTHONPATH set to import tahoe's
dependencies).
This funky invocation syntax was introduced in 2007 (commit 56ad518),
with a comment of "make pyflakes run faster". I no longer have any idea
why that might have been the case. It's time to simplify this, because
some of our buildslaves have pipsi-installed "pyflakes" on their $PATH,
which use a "python" that's different than the one on $PATH.
After extracting the contents of the package, this script looks at the
output of 'tahoe --version-and-path' to see if the modules are installed
and invoked from the right path.
Author: Ramakrishnan Muthukrishnan <ram@leastauthority.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
