Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

building native binary wheels for fonttools and publishing them to PyPI #3116

Closed
anthrotype opened this issue May 22, 2023 · 3 comments
Closed

Comments

@anthrotype
Copy link
Member

FontTools contains a bunch of cython-accelerated modules (notably fontTools.cu2qu, plus others) that are only available when compiling the package from source (git clone or sdist) within an environment where cython and a compiler toolchain are available.

Ideally we'd build and publish these pre-compiled native binary wheel packages to PyPI, alongside the existing pure python wheel, so that when one pip install fonttools and a wheel is available for the target architecture, pip will download and install that automatically without the need to compile from source.

Right now fontmake/ufo2ft still depend on the standalone cu2qu for this exact reason, because for the old project we have set up and published binary wheels, whereas we have not yet for the new "upstream" copy that's in fontTools.cu2qu. The latter has received some additions lately (e.g a new all_quadratic=True parameter that can be set to False to let cubics in when advantageous) which have not been backported to the standalone cu2qu (which we did deprecate actually, though the repo isn't archived yet).

Anyway, I propose we set up a new repository at https://github.com/fonttools/fonttools-wheels where we pull in fonttools as a submodule and configure the Github Actions CI to build and publish the native wheels immediately after we cut new releases.
This way we do not make the current fonttools CI slower by adding a lot of builds for each combination of python minor version/ platform / architectures we'd like to support.

Ideally Cython would support Py_LIMITED_API so we can build a single wheel per platform, not one for each python minor version we support, but support for that is still not stable in cython (they are working on it but is buggy/experimenal and can't rely on that yet).

I'll do the work, just filing this in case others have different/better opinions.

@anthrotype
Copy link
Member Author

Looks like it worked!
https://pypi.org/project/fonttools/4.39.4/#files
https://github.com/fonttools/fonttools-wheels/actions/runs/5060028329

Let me know if you find any issues installing these binary wheels.

Note that if one really prefers not to install the precompiled binary wheel, one can always request the sdist with --no-binary option: e.g.

pip install --no-binary fonttools fonttools

The pure wheel is still on PyPI of course (e.g. pypy will download that one for I made no specific wheels for it, not worth it).

@anthrotype
Copy link
Member Author

I had to delete the wheel files I uploaded yesterday for the current PyPI release, since a user pointed out that the hashes for this release changed and this doesn't look good: #3120
Before next release, I will change the fonttools/fonttools CI configuration so that it will only build the native wheels upon tagged commits in preparation for the actual release, and then upload all of the sdist and wheel packages (both pure-python and native) in one go to PyPI, so there's no risk that hashes for a given release change (and we don't need a separate fonttools-wheels repository at all).

@anthrotype
Copy link
Member Author

binary (and pure-python) wheels are now available as of FontTools 4.40.0 https://pypi.org/project/fonttools/4.40.0/#files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant