Hi @jamesturk ,
Thanks for this very useful library!
This PR addresses the build of wheels with maturin.
The main changes are:
1 musllinux platform added
Some linux distros (e.g. alpine linux) don't use glibc but use musl. I followed the PEP-0656 and targeted musllinux. Maturin provides support for this platform, so just had to configure the build of the wheels.
Without these wheels, it may take half an hour to install jellyfish with pip from sdist.
2 interpreter selection in maturin
Instead of using setup-python and then --find-interpreter, if we use the explicit -i argument, we can list the interpreters for the build. This has 2 main advantages:
redundant builds: if you look the logs for the step Build wheels in your master branch (e.g. latest stable release), you will see that multiple python interpreter are found each time, and the matrix strategy iteration is repeating itself many builds of the same wheel.
reduction of the number of matrix strategy combinations: by listing all the interpreters at once, the cases are only by platform and not by interpreter.
deterministic list of built wheels: the --find-interpreter leads to compiled versions that are not declared anywhere, or to missing wheels (see last list below)
3 setup-python action not necessary to build wheels
Since maturin relies on virtualization to build the wheels, there is no need to setup python. The interpreter are declared and used inside virtualization.
Results
The results are that the same wheels are still being built (compare artifacts generated by workflow):
I tested some of the wheels in docker, and it seems to work on alpine linux without problems.
Maybe a step to test all the generated wheels should be done before releasing to pypi. I'
Hi @jamesturk , Thanks for this very useful library!
This PR addresses the build of wheels with maturin.
The main changes are:
1 musllinux platform added
Some linux distros (e.g. alpine linux) don't use glibc but use musl. I followed the PEP-0656 and targeted
musllinux
. Maturin provides support for this platform, so just had to configure the build of the wheels. Without these wheels, it may take half an hour to installjellyfish
with pip from sdist.2 interpreter selection in maturin
Instead of using
setup-python
and then--find-interpreter
, if we use the explicit-i
argument, we can list the interpreters for the build. This has 2 main advantages:Build wheels
in your master branch (e.g. latest stable release), you will see that multiple python interpreter are found each time, and the matrix strategy iteration is repeating itself many builds of the same wheel.--find-interpreter
leads to compiled versions that are not declared anywhere, or to missing wheels (see last list below)3 setup-python action not necessary to build wheels
Since maturin relies on virtualization to build the wheels, there is no need to setup python. The interpreter are declared and used inside virtualization.
Results
The results are that the same wheels are still being built (compare artifacts generated by workflow):
In addition, the following wheels are being generated for musllinux:
And the following ones are generated, that were lost by the
--find-interpreter
parameter.I tested some of the wheels in docker, and it seems to work on alpine linux without problems. Maybe a step to test all the generated wheels should be done before releasing to pypi. I'
Feel free to further edit or comment!
Best, Martino