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
The 'make build' target now runs 'setup.py build_tahoe', which figures out
where the target 'supportlib' directory should go, and invokes 'setup.py
develop' with the appropriate arguments.
The 'make test' target now runs 'setup.py trial', which manages sys.path and
runs trial as a subroutine instead of spawning an external process. This
simplifies the case where Twisted was built as a dependent library (and thus
the 'trial' executable is not on PATH).
setup.py now manages sys.path and PYTHONPATH for its internal subcommands, so
the $(PP) prefix was removed from all Makefile targets that invoke setup.py .
For the remaining ones, the 'setup.py -q show_pythonpath' subcommand was
added to compute this prefix with python rather than with fragile
shell/Makefile syntax.
Remove docs/install-details.html and README.win32 for now (see #282).
Remove checks for pywin32 and pyopenssl in Makefile -- that is (or will be) automated by setuptools.
Remove twisted from setup_requires. This causes the problem in which Nevow doesn't declare its dependency on Twisted (#440) to yield a clear ImportError mentioning Twisted and to fail repeatedly, rather than yielding a weird ImportError and working on the second identical attempt.
Fix Makefile to set PATH so that trial and twistd can be found by "make test" after Twisted was installed into support/ during "make"
Using pkg_resources.require() like this also apparently allows people to install multiple different versions of packages on their system and tahoe (if pkg_resources is available to it) will import the version of the package that it requires. I haven't tested this feature.
Now we use "./setup.py develop" to ensure that changes to our source code are immediately used without requiring a "make" step. This simplification will hopefully pave the way for easier py2exe and py2app, solving the "Unit tests test the installed version" bug (#145), and perhaps also #164 and #176.
This patch also conditionalizes the use of setuptools_darcs on the absence of a PKG-INFO file, which is part of fixing #263.
Technically, we could get away with v0.6c5 or v0.6c4 on non-cygwin platforms, but if someone currently doesn't have setuptools >= v0.6c6 installed then our setup process will just use our bundled setuptools v0.6c7 anyway, so it will still work, and this makes the setup.py and the accompanying documentation simpler.
Unfortunately, there is no way to claim that we are under a Free Software/Open
Source licence without also claiming to be under a licence that we are not or
claiming to have approval from DFSG or OSI, which we haven't.
Until now, I erred on the side of choosing the licence that is closest to our
from the list (GPL), but that was a bad idea and now I'm erring on the side of
not including a machine-readable licensing claim at all.
Hopefully humans who are interested will quickly find out that we are actually
under a Real Free Software Licence.
But really, this underscores that we need to talk to FSF, edit our licence for
clarity of intent, and submit it to DFSG/OSI.
