I believe it's enough to test pypy implementation only on Linux.
We don't really need to also test it in on OSX, as fonttools is a pure python project so it should just work there as well.
Travis CI has just become too slow...
This reverts commit a63e1ed5d37797ee361b0a23d09bf8a03aaee23d.
The default OSX Travis worker is now osx10.11-xcode7.3 so we don't need to separately test the latter as it's now default.
Also, since the OSX are getting quite slow lately, we can't afford to test two different python2.7 on OSX; so from now on we just test the system Python 2.7.11 that comes with El Capitan (so no more 2.7.5 on Mavericks).
If a named instance has a PostScript name, the name is now printed as
a comment into the XML dump. Also, unit tests on `fvar` are now
exercising all code paths, both with and without PostScript names.
I had to remove the comments because bumpversion will strip them out anyway upon re-writing the updated version string in setup.cfg file.
Similarly, I had to normalize the whitespace like bumpversion would do. :-/
`tag=True` option means a tag is automatically created when bumping the version with bumpversion script.
However, in order to get 'annotated' instead of 'lightweight' tags -- i.e. the tag also contains the tag author, date and message --, we need to (temporarily?) use a fork of bumpversion that includes an unmerged PR: https://github.com/peritus/bumpversion/pull/58
We need this as we no longer use setuptools_scm to retrieve the full list of files under version control.
Instead, we need to spell them out one by one.
Hopefully we don't forget anyone...
We must coerce name strings with `tounicode` because, on Python 2, the ElementTree library that we use to parse the designspace's XML will return ASCII-encoded `bytes` (PY2 `str`) whenever it can; and only returns `unicode` (PY3 `str`) when strings can't be encoded as ASCII... :(
However the `addName` method requires unicode strings (it wouldn't be able to encode them with multiple platform-specific encodings otherwise).
So we decode bytes as ASCII before passing them to addName.
previously (only on Python 2), the following line was silently coercing to Unicode using default 'ascii' encoding, whenever the input string was a `bytes` string (same as `str` in PY2):
namerecord.string = string.encode(namerecord.getEncoding())
On Python 3, the line above would crash, since bytes objects don't have an `encode` method (and rightly so).
`setName` should now accept both Unicode or bytes, but will issue a warning if the latter are used.
