Build custom wheels for each target Python version and OS

[matthewfeickert]

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 for iminuit and azure-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.

[henryiii]

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¹, 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.

Footnotes

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. ↩

[henryiii]

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.

[kratsg]

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?

[henryiii]

Yes, of course. A universal wheel requests a dependency just like any other, and pip then decides how to install the package.