Open matthewfeickert opened 5 years ago
Note: Universal wheels are far superior to binary wheels if you are using pure Python only. You only want non-universal wheels if you have compiled components[^1], so you don't really ever get to choose which you want. If you want to add a compiled component, then you need to change wheel types.
Binary wheels will never support some systems, like Alpine Linux, Clear Linux, and others.
[^1]: Or if you have different Python code for different Python versions, but this is very, very rare - it was only there to support the 2to3 script and no-one uses that anymore, it was a bad idea.
PS: You can test with each of these systems though, on the universal wheel you make, that's not a bad idea, and maybe what you are referring to.
PS: You can test with each of these systems though, on the universal wheel you make, that's not a bad idea, and maybe what you are referring to.
Does this mean that if pyhf
itself aims to be pure-python -- but does depend on non-universal-wheeled packages (e.g. tensorflow) -- this is still possible?
Yes, of course. A universal wheel requests a dependency just like any other, and pip then decides how to install the package.
Description
Following up from
awkward-array
Issue 143, it would be good to test wheel building for every pyhf supported Python version and operating system rather than just the universal wheel we currently produce. @henryiii has done some awesome work on this already foriminuit
andazure-wheel-helpers
using Azure pipelines. As this moves forward with scikit-hep projects it should be tracked and hopefully painlessly brought into pyhf as well.