The Linux distribution porting code was obsolete (using Python APIs not present
in Python 3, /etc/lsb-release isn't a thing on Fedora 31, for example), so
replaced it with maintained third-party library.
- Use the subunitv2-file reporter to allow for nicer error handling
- Undo the depgraph.sh change, see if it really matters
- Rename passing -> ratchet-passing to distinguish from ported modules
tracker
- Misc. documentation and ratchet.sh improvements
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
