Windows does not like when we open README.rst using builtin open():
Traceback (most recent call last):
File "setup.py", line 360, in <module>
long_description=open('README.rst', 'rU').read(),
File "c:\hostedtoolcache\windows\python\3.6.8\x64\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 1720: character maps to <undefined>
Under the right conditions (with newer Python 3.x versions), we will
see this warning:
setup.py:360: DeprecationWarning: 'U' mode is deprecated
`U` is for `universal newline mode`. Docs for open() says this:
'U' mode is deprecated and will raise an exception in future versions
of Python. It has no effect in Python 3. Use newline to control
universal newlines mode.
Off it goes.
Proceeding with caution here, because the txi2p-tahoe fork is rather
hurriedly done, and we are unsure about Tahoe-LAFS' i2p testing story.
None of the currently active Tahoe-LAFS contributors use i2p, so we
won't know if we are breaking things.
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
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
