This is all minor stuff: unreachable debug code (that should be commented-out
instead of in an 'if False:' block), unnecessary 'pass' and 'global'
statements, redundantly-initialized variables. No behavior changes. Nothing
here was actually broken, it just looked suspicious to the static analysis at
https://lgtm.com/projects/g/tahoe-lafs/tahoe-lafs/alerts/?mode=list .
Rewrote in Twisted, which lets us read/scan/print all log lines in
realtime. The output is now correctly interleaved (as well as
maintaining the stdout-vs-stderr of each message). The renamed
--warnings= logfile records all relevant lines from *both* stdout and
stderr (i.e. any that includes "DeprecationWarning"), which handles a
change (perhaps in recent Twisteds?) that emits these warnings on stdout
instead of stderr.
Tox doesn't run shell pipelines, and is unhappy about running tools that
it didn't install itself (including non-python things like "make"). So
this adds misc/build_helpers/run-deprecations.py, a python script that
runs a given command (i.e. trial) and writes stdout into a separate file
where the buildbot can see it, and counts the "DeprecationWarning" lines
from the file to decide the returncode.
This ought to improve the status display on the buildbot "test
deprecations" step.
This was used to exercise our old virtualenv-like scheme. Now that we
use virtualenv, they're unnecessary. Plus, removing it lets us stop
polluting end-user installs with the extra package (that might
conceivably conflict with some other project that names itself
"buildtest").
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.
The old scheme depended upon the bespoke pseudo-virtualenv scheme that
we cooked up long ago (it copied the entire source tree, bin/tahoe and
support/ and all, into the mac .pkg archive). When we moved to real
virtualenvs, that broke.
This new scheme only installs a populated virtualenv into the archive.
It replaces the entry-point bin/tahoe with a script that behaves a lot
like the old bespoke script: it inserts a relative site-packages/ into
sys.path before importing allmydata.scripts.runner and calling run().
This still depends upon the end-users $PATH having a python that is
compatible with the binary modules we've compiled here, and there are
three potentially-differing Pythons to worry about (homebrew, python.org
installers, and Apple's native /usr/bin/python). We'll have to see if
they tend to differ in ways that cause problems (I think the maintainers
generally try to avoid that). If that's an issue, the next level up is
to use bbfreeze or py2app or something in that category, to ship an
entire python, and not just a bundle of libraries.
As we fix ticket:#1582, we'll move to 'tox' for running tests (which
creates its own virtualenv), so I'd like to see which buildslaves
currently have it installed, and which need to be updated.
It looks like DockerHub's automated builds only have access to the
subtree of the source checkout at+below the Dockerfile. Putting the
Dockerfile in misc/build_helpers/ meant that the build process only had
access to misc/build_helpers/, not the full source tree.
Without stripping the single quotes, the generated pagkage filename
also has the undesired single quotes around the version string.
(eg: tahoe-lafs-'1.10.0.post309'-osx.pkg).
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>
