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.
Name it "trial_test_log.txt", so it can be read in a browser, not just
downloaded.
I'm hoping this will help track down why
test_magic_folder.RealTest.test_batched_process occasionally times out on
windows.
We aren't yet using these artifacts (we plan to build the production ones on
our buildbot machines), but this will make sure we don't break the process.
This commit contains a few small changes to fix PyInstaller frozen
builds (which were recently broken in a few ways by changes introduced
with `tahoe invite`, `tahoe daemonize`, and the addition of "setuptools
>= 28.8.0" to setup_requires) and removes a couple of hacks that are no
longer necessary to create working frozen tahoe executables with
PyInstaller.
The OS-X builders don't offer a python environment, so we have to build
things ourselves (installing tox/etc with --user, instead of into the
virtualenv that "language: python" gives us).
* use 'extras' for our `[test]` additions instead of abusing 'deps'
* use 'deps' to pre-install 'incremental', which we couldn't do when we
filled it with --editable to get `[test]`
* pre-install 'incremental' to work around a bug that strikes on Travis under
OS-X-10.12 as PyPI gradually disables TLS<1.2. See ticket 2913 for details
* remove redundant configuration lines
* require tox-2.4 or newer, to get 'extras'
refs ticket:2913
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2913
Thanks to exarkun for the suggestion. The failing buildbots have LANG unset,
but I'm pretty sure that defaults to LANG=C, and LANG=C triggers the failures
just as well as LANG= did.
Exercising the unicode possibilities are nice, but not critical to this test,
so let's just avoid the non-ascii characters when the filesystem encoding
can't handle them
to catch things like ticket:2912
(https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2912)
Also clean up other "list"-ish keys to avoid causing too many builds:
* "os": move this into "matrix"
* "python": 2.7 is the default, and we weren't running the pypy build
anyways (not sure why, something else in this config must have disabled it,
maybe when we moved away from language: python)
* "allow_failures" was causing a pypy build to happen even without listing it
in "python"
We now have exactly three builds:
* linux
* linux with LANG=
* OS-X
This was flunking the OS-X buildbot, which runs in an environment without
$LANG being set, and thus encodingutil deduces (correctly but unhelpfully)
that we're limited to ASCII. Other tests detect this situation and raise
SkipTest, so let's do that here too.
There appears to be a bug in setuptools, triggered by running "python
setup.py sdist" with setuptools==11.3 in that python's environment, on a
project whose setup.py has a setup_requires= that requests setuptools >=
28.8.0. When setuptools is upgraded from inside setup.py, it gets into a
weird hybrid state where it's using setup() keyword-argument plugins from the
newer setuptools, but those plugins reference functions that aren't present
in the older setuptools, and the sdist command fails with an import
error (module object has no attribute 'check_specifier').
We don't actually need the sdist: all our tox test environments use
"skip_install = true", because we install tahoe via the "deps" line (so we
can get the `[test]` extra, and get a faster symlink-ish "editable" install).
That install uses "pip", which uses the pip inside the new virtualenv, which
either uses a newer version of setuptools (dependent upon what version of
"virtualenv" was installed in the parent environment, next to tox) or somehow
allows setuptools to be upgraded without exposing this weird broken hybrid
state.
Either way, skipping the sdist seems to fix this problem.
refs ticket:2910
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2910
This should also (hopefully) fix the LGTM baseline build, because they appear
to downgrade all dependencies to the lowest declared-acceptable version
before performing their static analysis, and the previous setuptools-11.3 was
too old to support some of the syntax used in zfec's setup.py (specifically
the python clause in `"argparse > 0.8 ; python <= '2.7'"`).
PR 470 updated the declared setuptools requirement, but it broke Travis on
OS-X because that platform had a really old setuptools-18.5, and apparently
upgrading from 18.5 to the current 39.0.1 during the tox process caused
internal consistency problems (probably mixing pieces of the two different
setuptools modules). This branch fixes it by telling travis to upgrade
setuptools before we run tox.
closestahoe-lafs/tahoe-lafs#470
The Travis OS-X worker has a very old setuptools-18.5 in /System. This is too
old to understand several important setup.py keys like `python_requires`, and
crashes when tryung to run the first invocation of tox (`tox -e codechecks`).
I think tox is using the system python (with which `tox` was invoked) to run
`setup.py egg_info` (to learn the dependencies), which gets the old
system-installed setuptools. Ideally it'd use the python from the
newly-created virtualenv, which would use whatever version of setuptools was
bundled with the `virtualenv` package (probably newer, given that
`virtualenv` itself should have been installed a moment earlier as a
dependency of `tox`.
I consider this a bug in Tox (https://github.com/tox-dev/tox/issues/507), but
the workaround is to configure Travis to install the most recent `setuptools`
along with `tox`.
refs tahoe-lafs/tahoe-lafs#470
