Our install_requires= want foolscap>=0.10.1, and this check only fired
if we were given <0.6.4, so the check should be obsolete.
Also, the check was breaking my attempt to test Tahoe against a
development release of Foolscap, as the NormalizedVersion call threw an
IrrationalVersionError at my Versioneer-based "0.10.1+14.g37d8279"
version string.
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 allows a python3-based "tox" (as shipped with modern debian and
ubuntu systems) to run setup.py egg_info, update_version, and sdist
commands. It moves the main "tahoe requires py2" check out of setup.py
and into allmydata.scripts.runner.run, where it gets applied at runtime
rather than build time.
It also changes the execfile(_auto_deps.py) and Versioneer-like "ask git
what our version string should be" code to work under both py2 and py3.
fixes ticket:2747
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 removes the "setup.py trial" and "setup.py test" aliases from
setup.cfg, and the custom Trial class from setup.py .
Note that once you have tahoe installed into a virtualenv, "trial
allmydata" is how tests are actually run (that's what tox does).
Having a command for it in setup.py offered two things: a common
setup.py-based target to start tests (like "make check" in a
GNU/automake -style project), and a convenient way to get the
PATH/PYTHONPATH right. "tox" is now the standard way to invoke tests in
python projects, and tox sets up $PATH for us.
We don't necessarily need this ourselves (__init__.py's version-checking
code is the only thing in tahoe per se that uses setuptools, and our
setup.py's use of setuptools isn't something that install_requires= can
say anything about). But at least one old environment failed because a
sub-dependency needed a newer version than Tahoe asked for. I'm not sure
if this ought to be here, but it may help for a transitional period
until these ancient environments get updated.
closes ticket:2744
20.3 is the current version as of today. I'm not really sure what
version we need, but this is better than the previous zetuptoolz "0.6c6"
requirement. Closes ticket:2744.
Our setup.cfg ensures that 'setup.py update_version' happens early
enough. And doing it from tox's commands= is too late anyways (because
we aren't using Versioneer, so the _version.py file must be updated
before tox installs a static copy into the virtualenv).
The buildbot's main run-trial-with-tox command has been updated to scan
for the 'tahoe --version' output and include the version string in the
buildbot results.
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.
With our new tox/pip/virtualenv -based environment, we no longer need
the bin/tahoe script, so the tests that examine it needed to change.
In particular, we no longer need to be running tests from the root of a
source tree. Instead, what we care about is that the subprocess 'tahoe'
is importing code from the same place that the unit test .py files live.
This is more cleanup from the 1582 zetuptoolzs-ectomy. __requires__ was
used to make sure that 'setup.py test' would have all our dependencies
on sys.path, but has the severe drawback of requiring all deps to be
available before any setup.py command can work, including the 'setup.py
sdist' that tox uses (to populate the new virtualenvs it creates). Now
that we use tox for tests, we don't need 'setup.py test' any more, but
I'll remove that later (after this release). Right now we just need to
get rid of this __requires__ line, as it was causing 'tox' sdist
failures.
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.
