Closed grlee77 closed 1 year ago
In general, I'd say cibuildwheel
is better maintained and (importantly) has decent documentation. multibuild
does the job, but the bash + git submodules approach is a giant pain.
PyWavelets is in low-activity mode, so I'm not sure how much work the move would be, but if you think it's doable and we can sync the changes from scikit-image fairly easily, then let's go for it.
The one thing that has been quite useful in having a separate repo (like https://github.com/MacPython/pywavelets-wheels) for wheel builds + PyPI uploads is better security. This is why we weren't badly affected by the Codecov security incident for NumPy and SciPy for example. Had we had that on the main repo, it would have been a massive pain. A staging area and a single "this looks okay, let's run twine
" step for the release manager is probably a good thing.
Anyway, for PyWavelets it's less of an issue - happy to follow scikit-image's approach here.
This was done, closing.
@leej3 and @viniciusdc worked on an automated wheel build and upload process for scikit-image in https://github.com/scikit-image/scikit-image/pull/5397
I am opening this issue to solicit feedback on whether it makes sense to take a similar approach here. In past releases, we used multibuild in the pywavelet-wheels repo to stage wheels on Anaconda and then manually downloaded them for upload to PyPI with twine.
@rgommers, do you have a good sense of whether it is preferable to keep the current
multibuild
approach or move tocibuildwheel
? I haven't tried using multibuild in our PyWavelets repo in at least 6 months, so am not sure if it is still working as-is or if some updates would be required. I am asking because I think it would be good to create a 1.2 release here relatively soon.Our multibuild scripts currently rely on Travis-CI for the linux and osx wheels.