At the time we pinned this to v219, I think the v220 on PyPI was broken for
py2.7, or they'd stopped producing newer wheels for py2 but the most recent
py2-capable one was broken. The upstream bug is fixed, so I'll unpin this and
see if it works.
This allows a python3-based tox (as is common on modern debian/ubuntu
systems) to test our py2-only package. The first thing Tox does is to build a
wheel to install into the target virtualenv (which is a py2-based venv, for
tahoe). But Tox bug (https://github.com/tox-dev/tox/issues/507) in which this
wheel is built with the same python that Tox is using, instead of the python
from the target environment. Our setup.py would see sys.version_info with py3
and launch a crowbar into the works.
With python_requires=, pip is smart enough to know that it's ok to build
wheels with the wrong python, but "pip install" still throws a sensible error
message:
```
(ve36) ~/stuff/tahoe/tahoe$ pip install .
Processing /home/warner/stuff/tahoe/tahoe
tahoe-lafs requires Python '<3.0' but the running Python is 3.6.1
```
Closes ticket:2876
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
