Previously this looked at sys.platform to decide what dependencies to
include. The problem with that approach is that wheels built on a unix box
won't work on windows (and vice versa), when the (pure-python) Tahoe wheels
aren't supposed to be platform-dependent.
setup.py provides a syntax to express this properly, so wheels created on
either platform will include the pypiwin32 dependency in the metadata, but
marked as only being relevant when installing on a win32 platform.
closes ticket:2763
This introduces a py.test-based integration suite (currently just
containing magic-folder end-to-end tests). Also adds a tox environment
("integration") to run them.
The test setup is:
- a "flogtool gather" instance
- an Introducer
- five Storage nodes
- Alice and Bob client nodes
- Alice and Bob have paired magic-folders
Now you can do `pip install tahoe-lafs[tor]` to get tor support.
The necessary support libraries are also installed with `[test]`, so
unit tests can rely upon importing txtorcon and friends.
We no longer need the complexity of choosing the application name at
runtime. This removes the setup.py code which populates the _appname.py
file, and the code in __init__.py which reads it. It does not yet remove
the tests which compare the output of e.g. `tahoe --version` against
`allmydata.__appname__`, which I think could be removed, but that's more
invasive than I want to do right now.
closes ticket:2754
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 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.
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.
Twisted 15 dropped support for it, which causes Travis CI tests to fail on 2.6.
We still theoretically support older versions of Twisted, so perhaps we should
configure Travis to test with those? I think we should drop Python 2.6 in any
case since distros are all on 2.7 now.
I'm leaving Travis running (and ignoring) the failing PyPy tests because I
don't know why that is there.
This simplifies reporting when we don't have the version. Also print the normalized version. refs #2340
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
(Note that if the version changes in future, this will fail loudly so we'll know we have to change it.)
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Closes ticket:2281 (trac).
This removes src/allmydata/test/trial_coverage.py, which was a
in-process way to run trial tests under the "coverage" code-coverage
tool. These days, the preferred way to do this is with "coverage run",
although the actual invocation is a bit messy because of the way
bin/trial uses subprocess.call() to invoke the real entrypoint script
with the right PYTHONPATH (see #1698 for details). Hopefully this will
be improved to use a simpler "coverage run .." command in the future.
This patch also removes twisted/plugins/allmydata_trial.py, which
enabled the "--reporter=bwverbose-coverage" option. Finally it modifies
setup.py to stop looking for that option and adding "trialcoverage" to
the dependencies list, which gets us closer to removing "setup_requires"
entirely.
setup.py: stop sometimes-depending upon 'stdeb'
setup.cfg: don't try to alias 'sdist_dsc'
misc/build_helpers/build-deb.py: delete this, it was really old anyways
Closes ticket:2282 (trac).
This uses explicitly enumerated packages= and package_data= arguments to
setup(), rather than relying upon the convenient (but darcs-specific)
functions which would determine these values by asking the revision-control
system.
Note that darcsver is still used, when building from a darcs tree.
allmydata.__version__ can just be a string, it doesn't need to be an instance
of some fancy NormalizedVersion class. Everything inside Tahoe uses
str(__version__) anyways.
Also add .dev0 when a git tree is dirty.
Closes#1466
This replaces the setup.cfg aliases that run "darcsver" before each major
command with the new "update_version". update_version is defined in setup.py,
and tries to get a version string from either darcs or git (or leaves the
existing _version.py alone if neither VC metadata is available).
Also clean up a tiny typo in verlib.py that messed up syntax hilighting.
The new tarball-building buildslave had a bogus umask set, causing the 1.9.0
tarballs to be non-other-user-readable (go-rwx), which is a hassle for
packaging. (The umask was correct on the old buildslave, but it was moved to
a new host shortly before the release). This should make sure tarballs are
correct despite the host's setting.
Note to others: processes run under twistd get umask=077 unless you arrange
otherwise.
Remove install.html (long since deprecated).
Also replace some obsolete references to install.html with references to quickstart.rst.
Fix some broken internal references within docs/historical/historical_known_issues.txt.
Thanks to Ravi Pinjala and Patrick McDonald.
refs #1227
It is currently hardcoded in setup.py to be 'allmydata-tahoe'. Ticket #556 is to make it configurable by a runtime command-line argument to setup.py: "--appname=foo", but I suddenly wondered if we really wanted that and at the same time realized that we don't need that for tahoe-1.3.0 release, so this patch just hardcodes it in setup.py.
setup.py inspects a file named 'src/allmydata/_appname.py' and assert that it contains the string "__appname__ = 'allmydata-tahoe'", and creates it if it isn't already present. src/allmydata/__init__.py import _appname and reads __appname__ from it. The rest of the Python code imports allmydata and inspects "allmydata.__appname__", although actually every use it uses "allmydata.__full_version__" instead, where "allmydata.__full_version__" is created in src/allmydata/__init__.py to be:
__full_version__ = __appname + '-' + str(__version__).
All the code that emits an "application version string" when describing what version of a protocol it supports (introducer server, storage server, upload helper), or when describing itself in general (introducer client), usese allmydata.__full_version__.
This fixes ticket #556 at least well enough for tahoe-1.3.0 release.
also specify that we need our latest revision (11dev) of our toothpick of setuptools
also *always* setup_require setuptools_darcs at module import time. Formerly we added setup_require setuptools_darcs only if the PKG-INFO file were not already created. There is some weird, irreproducible bug to do with setuptool_darcs, and I guess that the fact that whether it is required or not depends on that autogenerated file might have something to do with it. Anyway, this is simpler.
Create the 'tahoe-script.py' file under the 'bin' directory. The 'tahoe-script.py' file is exactly the same as the 'tahoe-script.template' script except that the shebang line is rewritten to use our sys.executable for the interpreter. On Windows, create a tahoe.exe will execute it. On non-Windows, make a symlink to it from 'tahoe'. The tahoe.exe will be copied from the setuptools egg's cli.exe and this will work from a zip-safe and non-zip-safe setuptools egg.
When this feature is turned on, then setuptools doesn't create easy-install.pth, setuptools.pth, or site.py in the target site-packages dir. I don't know why not and we should probably open a ticket on the setuptools tracker and/or hack setuptools to create those files anyway. But for now (for the Tahoe-1.3.0 release), we're going to leave --multi-version mode off and require users to manually uninstall any packages which are too old and thus conflict with our newer dependencies.
We'll see if this fixes the tests on all of our current buildslaves, and if it does then I'll be happy to leave it at "> 1.8.1" for now, even though I don't know exactly what versions of simplejson changed exactly what behavior that interacts with exactly what environment. See http://allmydata.org/trac/tahoe/ticket/534 for uncertainties.
zooko helped me unravel a build weirdness today. somehow the system installed
twisted (/System/Library) was pulling in parts of the other twisted (/Library)
which had been installed by easy_install, and exploding.
getting rid of the latter helped, but it took this change to get the tahoe
build to stop trying to rebuild twisted and instead use the one that was
already installed. c.f. tkt #229
