I tested this locally (on MacOS) against python3.7.0, and it now works. This
will appear broken on travis/appveyor until those CI environments add support
for py3.7 (but the failures should be ignored since py3.7 is in the
'allowed_failures' list).
closes#306
See https://bugs.python.org/issue26175 . tempfile.SpooledTemporaryFile
doesn't fully implement the IOBase abstract class, which breaks because
py3.7.0's new zipfile module tries to delegate .seekable down to the wrapped
file and causes an AttributeError.
refs #306
The servers were moved out to separate repos (magic-wormhole-mailbox-server
and magic-wormhole-transit-relay), and I think this Dockerfile was building
an image mostly to run the mailbox server.
It might make sense in the future to have a Docker image for just the client,
in which case it'll be time to bring these Dockerfiles back with different
contents.
refs #295
The flake8 config excludes E741, which would complain about using
'l' (lower-case ell) as a variable name. We use this for the Lister object in
one test that uses single-character variable names for all the machines ('b'
for Boss, 'm' for Mailbox, etc). That comment was added before excluding
E741. If we ever restore that warning, we might want to rename the variable.
We care about how long it takes to import all the wormhole-specific things,
to investigate user-perceived latency from the time the command is launched
to the time they can actually interact with it. So we need to record
`time.time()` before doing the rest of the imports, even though pep8 says all
imports should be done before any non-importing statements.
The new PyPI code discards long_description when it's not valid ReStructuredText. Luckily it also supports Markdown, but you have to [specify the content type](https://packaging.python.org/tutorials/packaging-projects/#creating-setup-py) explicitly in that case.
(IIRC for this to work correctly you also have to use sufficiently recent versions of setuptools and twine to upload releases.)
Should fix#303.
tested with/on:
- ubuntu linux 18.04 amd64
- pyinstaller 3.3.1 (pip install pyinstaller)
- python 3.6.5
There is a good chance it also works on FreeBSD, maybe also on macOS.
The change in __main__.py was required because otherwise it complains about
__main__ not being a package when trying the dot-relative import.
Also make sure to ignore E741 naming a variable as l will raise this error and
reason is l is similar to 1 and people might get confused. For me it doesn't
look like an error hence ignored in tox.ini
This factors out the various "get me a Deferred which fires when/if we
compute a value" code from the _DeferredWormhole API calls: get_code,
get_unverified_key, get_versions, get_message, etc. It uses an eventual-send
for each one, which will protect against surprises when an application
invokes an wormhole API from within a previous API's callback: without this,
the internal wormhole state isn't guaranteed to be coherent, and crashes
could result.
Tests can pass an EventualQueue into wormhole.create(), to override the
default. This lets the tests flush the queue without using a haphazard
real-time delay.
closes#23
(in fact, we added multiple-Deferreds-per-API a while ago, but this does it
in a much cleaner fashion, and with the safety of an eventual-send)
This factors out the various "give me a Deferred for an value that may or may
not eventually be successfully generated" routines in _DeferredWormhole. It
uses an eventual-send to fire the Deferreds to avoid plan-coordination
hazards when the attached callbacks then call back into the Wormhole object
before the rest of the state transition has finished.
We defer starting a new timer until we've completely emptied the queue, since
we know we'll get to any new events added inside one of our callbacks. The
old design in Foolscap (which copied the list, cleared the original, then
fired everything in the copy) didn't look at these new events. OTOH, this
pop(0)-until-empty approach makes it easier to get into an infinite loop (any
callback which queues a new callback will get priority over anything else).
But the code is simpler.
Python.org is still supporting 3.4, but the lastest pypiwin32 stopped
providing binary wheels for windows for 3.4, so we can't run the appveyor CI
tests any more. It might still work there, but you'll have to find a way to
build pypiwin32 yourself.
We still support py3.4 on non-windows platforms.
