https://travis-ci.org/anthrotype/fonttools/jobs/123273641
When I do `pip install -r dev-requirements.txt` from within a virtual env,
jython sits for 3-4 minutes doing nothing, then the Travis shell exits with this cryptic error:
/usr/bin/env: python2.7: Argument list too long
I don't know why but when I `pip install -r requirements.txt` on Jython,
it always raises a Java StackOverflowError.
If I install the deps individually, it works...
$ pip install -v -r dev-requirements.txt
Exception:
Traceback (most recent call last):
File "fonttools-jy271b2/Lib/site-packages/pip/basecommand.py", line 209, in main
status = self.run(options, args)
File "fonttools-jy271b2/Lib/site-packages/pip/commands/install.py", line 285, in run
self.populate_requirement_set(
File "fonttools-jy271b2/Lib/site-packages/pip/basecommand.py", line 286, in populate_requirement_set
for req in parse_requirements(
File "fonttools-jy271b2/Lib/site-packages/pip/req/req_file.py", line 89, in parse_requirements
for line_number, line in lines_enum:
File "fonttools-jy271b2/Lib/site-packages/pip/req/req_file.py", line 323, in ignore_comments
for line_number, line in lines_enum:
File "fonttools-jy271b2/Lib/site-packages/pip/req/req_file.py", line 298, in join_lines
if COMMENT_RE.match(line):
RuntimeError: maximum recursion depth exceeded (Java StackOverflowError)
virtualenv is required by tox. Appveyor ships with virtualenv 13.x or something.
tox works fine with that.
However, virtualenv install its own embedded version of pip in the newly created environments. When we install the requirements.txt, pip complains that pip is not up-to-date. Updating virtualenv makes pip stop complaining.
Woosh.
Update appveyor.yml to follow the most recent recommendation from PyPA Packaging User Guide:
http://python-packaging-user-guide.readthedocs.org/en/latest/appveyor/
- set DISTUTILS_USE_SDK=1 only for Python34-x64. It seems like we no longer need to do that for Python2.7-x64;
For more info check this: https://github.com/ogrisel/python-appveyor-demo/issues/39
- run tox using 'with-compiler.cmd' batch script so that Brotli extension can be built from git source with the correct MSVC and Windows SDK versions (btw, I wish brotli was on PyPI already so we could just `pip install brotli` and done!);
- define TOXPYTHON variable to make sure tox uses the correct python interpreter. Previously, in fact, the 'py34' toxenv was always picking up the 32-bit interpreter, even when we were testing the 64-bit Python 3.4 :(...
- add PowerShell command to enable 'rollout builds' feature, as done on 'python-appveyor-demo':
f54ec3593b/appveyor.yml (L81-L89)
- call pip via `python -m pip` to make sure we are running the just updated pip version, instead of Appveyor's pre-installed pip
- Remove unused stuff
It seems like sets are hashed differently in CPython and PyPy.
Because of this, the returned list of class sets may have a different sort
order (within each class size) between the two implementations.
For now, I make the test pass on both CPython and PyPy by casting the returned
list of sets into a set of (frozen) sets, and asserting that its *content* is
correct, without considering the *order* of the sets in the list.
set objects have different __repr__ on python 2 and 3
Python 3:
>>> {1, 2, 3}
{1, 2, 3}
Python 2
>>> {1, 2, 3}
set([1, 2, 3])
(one among the several reasons I don't particularly like doctest...)
A couple of modules were relying on the fact that the 'sys' module was being implicitly imported by 'from py23 import *'.
The 'py23.__all__' does not include 'sys'. I think it's better to always import 'sys' explicitly when needed.