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
