Also it avoids the failure mode where a user forgets to activate the
virtualenv, types the recommended "pip install" command, and installs
stuff directly to their system instead of safely confined inside the
virtualenv.
This is only useful when running "setup.py install" directly, and is not
consulted when following our recommended "pip install .".
Platform-specific directories of wheels (that we, Tahoe, host ourselves)
are available for some platforms: these are described in
docs/INSTALL.rst and must be provided as a pip argument, not a
setup.cfg/easy_install configuration:
pip install --find-links=https://tahoe-lafs.org/deps/
This also removes our involvement with eggs (which, I believe, are
usually downloaded insecurely by easy_install).
* use correct fixed-width-font markup
* fix hyperlinks to neighboring (github-side) .rst files
* refer to python-2.7.11 consistently (thanks to PRab for the catch)
Thanks to dstufft for the suggestion. I know this can make it slightly
easier to run tahoe in some funny environments (where an appropriate
"python" is on your path but the generated "tahoe" executable is not).
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.
