scikit-hep / pyhf

pure-Python HistFactory implementation with tensors and autodiff
https://pyhf.readthedocs.io/
Apache License 2.0
285 stars 84 forks source link

Build custom wheels for each target Python version and OS #479

Open matthewfeickert opened 5 years ago

matthewfeickert commented 5 years ago

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

henryiii commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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