Releasing precompiled binaries of awkward-cpp

[jpivarski]

Just academically at the moment (no pressing need yet), but do you have any suggestions for how to release binary distributions of awkward-cpp, @matthewfeickert and @henryiii? I've been fiddling with the .travis.yml for 0.11.0 and managed to get

• awkward to make a source and a universal wheel from Python 3.7, Numpy 1.15+ only
• awkward-numba to make a source and a universal wheel from Python 3.7, Numpy 1.15+ only
• awkward-cpp to deploy from Pythons 2.7, 3.5, 3.6, and 3.7 but only Numpy 1.15+, which would be perfect if it would make binary distributions, but "bdist_wheel" complains and "bdist" makes a source distribution. (Thus, the four Python versions are a race condition.)

Any thoughts? Henry and I had talked about this earlier, and he's led the way with Boost-Histogram, but I think he's using the Azure pipeline. I guess we could move everything over from Travis to Azure, but it sounds like a lot of work that I'd like to avoid.

[henryiii]

Still getting settled in here, but a few thoughts:

• For universal wheels, any technology works, and Travis's deploy universal wheel feature is quite nice.
• For C++ wheels, you don't want the entire matrix to build every commit - macOS, windows, and linux times 32 and 62 bits times 3-4 Python versions, along with the special setup required to make universal wheels on each platform. Since it should be a different pipeline anyway, it makes sense to implement it in Azure and leave Travis for per-commit/PR testing.
  • The scripts at https://github.com/scikit-hep/azure-wheel-helpers should be pretty much drop in and go
  • https://github.com/joerick/cibuildwheel is an interesting project - they've added Azure support recently, and also support the other major platforms. I'd like to try this out before going all in on azure-wheel-helpers

[matthewfeickert]

@jpivarski For pyhf we only distribute a source dist and universal wheel for the time being. I think that the suggestions that @henryiii has made are quite good, and I don't really have anything to expand there. Henry has already shown this to work well with iminuit. This is an interesting issue to me as it would be good for pyhf to expand our wheel collection as well.

[jpivarski]

I've been having Travis deploy only on releases (tags), not every commit, and I've been using conditions to select elements from the matrix, which I'd hoped to use to cover each build (fewer than every test, but we need built versions for every Python version and operating system, right?).

If it's possible to run Travis and Azure, then that could be ideal. I could leave Travis as it is for all of the testing and source package deployment (awkward, awkward-numba, and maybe awkward-cpp) and Azure for the matrix of Python versions and operating systems, triggered in new tags, to build binaries for awkward-cpp only. That way, I'm creating a workflow only for the part that doesn't work yet.

Thanks for the suggestions!

[matthewfeickert]

I've been having Travis deploy only on releases (tags), not every commit,

Yeah, that's what pyhf does as well

and I've been using conditions to select elements from the matrix, which I'd hoped to use to cover each build (fewer than every test, but we need built versions for every Python version and operating system, right?).

Yup. Building custom wheels is the nice thing to do, which pyhf needs to start doing too.

If it's possible to run Travis and Azure, then that could be ideal. I could leave Travis as it is for all of the testing and source package deployment (awkward, awkward-numba, and maybe awkward-cpp) and Azure for the matrix of Python versions and operating systems, triggered in new tags, to build binaries for awkward-cpp only. That way, I'm creating a workflow only for the part that doesn't work yet.

I think this model of testing the source with Travis and then testing the wheel building with each PR and then deploying wheels on releases with Azure sounds like a really good idea. cc-ing @lukasheinrich @kratsg on this as well, as this sounds like a good direction for all of the scikit-hep related projects to start moving. So I guess a big thanks to @henryiii for getting this whole thing going!

[henryiii]

Soon (next week?) I should have some time to help set this up. I think having Azure handle building and Travis handle testing is a good setup for now. I want to look into two ideas before we outfit the rest of our packages with wheels, but hopefully that won't take long.

[kratsg]

@henryiii for clarification -- do you need version commits to bump the versions? I assume you do. Are you handling tagging via a PR into master, and then when master has been tagged -- run the deployment chain with Azure, etc...?

[henryiii]

The version needs to be different for each PyPI release, you can't overwrite a release, but otherwise, no, you do not need any commits. You click a button in the Azure web interface and the release pipeline runs on the artifacts built by the build pipeline. You can manually trigger that too if you want, on any commit. It's very flexible and you have full control - very nice for something as irrevocable as PyPI releases. You can, in theory, automate it on tags but I haven't managed yet and haven't tried very hard.