Apparently on some BSD systems man pages go to /usr/man instead of /usr/share/man.
It's too complicated to keep track of all the nuances of Linux distros so package maintainers can simply override the default via a $FONTTOOLS_MANPATH env variable
Fixes#84
It's not a good thing that we build different wheel packages (with/without data_files) according to the platform we build them with.
After all, these wheels are meant to be "universal".
Even when manpages can't be used on a target platform (e.g. Windows), their mere presence should not do any harm; they are simply copied to a 'share/man' folder relative to the python prefix. On Unix systems (Linux, Homebrew, etc.) this is usually `/usr` or `/usr/local`, so `man ttx` just works (TM).
Note that other popular python tools like IPython or Sympy also install manpages the same way we do here with ttx, and they do that unconditionally for all platforms.
As regards issue #796, whereby attempting to `sudo pip install fonttools` fails because the manpage file is copied to a SIP-protected location on OSX El Capitan and above:
Users who still wish to install fonttools globally with sudo (and are not scared after googling 'why sudo pip is bad'), can still use the '--install-data' option of setup.py install to modify the data_files base installation directory.
If you install with pip (recommended over `python setup.py install`), you can use --install-option to pass through installation options to setup.py (which is run by pip when installing from source).
For example, to install man pages to /usr/local/share/man/man1/*.1 you could pass "/usr/local" as the base directory for --install-data, like so:
sudo -H /usr/bin/python -m pip install --install-option="--install-data=/usr/local" fonttools
This makes sure we upload the same files to Github Releases and PyPI.
Currently we were building them twice, with the risk of different files
being uploaded to the two repositories.
ttx is now equivalent to:
$ fonttools ttx
pyftsubset can be called as:
$ fonttools subset
varLib can be called as:
$ fonttools.varLib
Also adds a executable at toplevel called fonttools, such that
with "./fonttools ..." one can run stuff without installing.
Python seems to automatically include ./Lib into its search path.
setuptools_scm handles managing python package versions using git metadata instead of declaring them as the version argument or in a git-managed file.
https://github.com/pypa/setuptools_scm
This reverts commit fe90e12601b9bea3983ddc1c0ec58303d14bbbe3.
Khaled commented:
> We either need to update the man page or find a way to generate it from other
existing documentation, not just drop it entirely with no replacement
fe90e12601 (commitcomment-18713586)
One notable absence was README.md... :)
For the testdata/*, I now use `include_package_data=True` in setup.py, to automatically install any data files found inside package directories that are also specified in MANIFEST.in file.
I also include the Snippets, which I think should belong to the source distribution, despite not being installed as console scripts like ttx, etc.
The MANIFEST.in does not need to include itself (done by default).
There's no point in installing the test modules if we don't also install the test data.
(BTW, all this stuff would not be necessary if we were to use 'setuptools_scm'
which would just include in the distribution all the files which are tracked by
git version control...)
The file contains outdated information and nobody is maintaining it any longer.
Plus it only works on Linux, and only if pip installing as sudo (which is bad!).
We need proper Sphinx+ReadTheDocs kind of documentation.
Python's stdlib
The 'xml.parsers.expat' module has been a part of Python's Standard Library since version 2.0. Link: https://docs.python.org/2/library/pyexpat.html#module-xml.parsers.expat . FontTools requires Python 2.7, or Python 3.3 or later. Checking for the existence of this module is not necessary anymore.
