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.
Since py23 modifies some essential builtins, it's safe to import
everything all the time. At least, that's how it was designed.
It's a bug if importing * breaks some code.
The previous 'allXMaxIsLsb' name was misleading.
The 'allXMinIsLsb' boolean variable cooresponds to the head table's Bit 1.
This is set whenever all glyphs have the bbox.xMin equal to the respective
left sidebearing (and therefore "left sidebearing point at x=0").
Today, Apple has kindly fixed a bug in the [specification of the
meta table](https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6meta.html). The existing fonttools implementation matches the
revised specification. Therefore, the comments about fonttools
intentionally deviating from Apple's spec can be removed.
'featurefile' can be either a path (string) or a file object, like in TTFont or XMLReader and XMLWriter constructors.
If a file object does not have a 'name' attribute, a default "<features>" name is
used and the current working directory is assumed as the root for relative includes.
