This is all minor stuff: unreachable debug code (that should be commented-out
instead of in an 'if False:' block), unnecessary 'pass' and 'global'
statements, redundantly-initialized variables. No behavior changes. Nothing
here was actually broken, it just looked suspicious to the static analysis at
https://lgtm.com/projects/g/tahoe-lafs/tahoe-lafs/alerts/?mode=list .
This moves all magic-folder configs to a single YAML
file. We load legacy config fine and don't mess with
legacy config unless you use a magic-folder command that
changes the config.
Increase test coverage
get_listener() is allowed to return either, and the Tor provider is currently
simple enough to not really need more than a basic descriptor, but have it
return a full Endpoint for use as an example of what I2P can do later.
This delegates the construction of the server Endpoint object to the i2p/tor
Provider, which can use the i2p/tor section of the config file to add options
which would be awkward to express as text in an endpoint descriptor string.
refs ticket:2889 (but note this merely makes room for a function to be
written that can process I2CP options, it does not actually handle such
options, so it does not close this ticket yet)
This sets the stage for further changes to the startup
process so that "async things" are done before we create
the Client instance while still reporting early failures
to the shell where "tahoe start" is running
Also adds a bunch of test-coverage for the things that got
moved around, even though they didn't have coverage before
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
This removes some code in dictutil.py that we weren't using, or which could
be replaced by something simpler. This code is troublesome, because our unit
tests only achieve intermittent coverage, so other (unrelated) PRs are
failing CI when the coverage appears to go down.
I tried to improve the tests to reliably cover everything in dictutil.py, and
discovered code that couldn't possibly have worked in the first place. So the
easiest approach was just to delete it all.
refs ticket:2891
It looks like str() was meant to truncate the dict, but a missing i+=1 meant
that it never actually did. I also changed the format to include a clear
"..." in case we truncate it, to avoid confusion with a non-truncated dict of
the same size.
This also improves test coverage in subtract() and
NumDict.item_with_largest_value().
refs ticket:2891
travis apparently behaves like buildbot's ERROR_UPON_ERROR, rather that
HALT_UPON_ERROR, and if the tor install fails, then the integration test's
last step is certain to fail.
This opens a wormhole and sends appropriate JSON down
it to a tahoe-gui using a wormhole server running on
tahoe-lafs.org
The other end uses the 'tahoe create-node' command (with
new --join option) to read the configuration JSON from
a 'tahoe invite' command
