-
Notifications
You must be signed in to change notification settings - Fork 15
staging wheels at anaconda.org #42
Comments
Thanks for the options, @grlee77! Yes I have various emails about this flagged in my inbox but I have not acted upon them. For now, I'm definitely happy to go with multibuild-wheels-staging. I do want to move to a future where GitHub Actions auto-uploads wheels to PyPI directly on tagging, like napari does. That might actually be easier than this transition, I'm not sure. @hmaarrfk might have ideas! |
I'm not sure how GitHub actions changes the workflow for uploading automatically to pypi. Previously, we didn't want partially broken wheels to be uploaded by accident |
lets leave that as a seperate issue. |
It is fine if the team ends up with a different approach, but I went ahead and made #43 while the details of how to do this were still fresh on my mind. I do think GitHub Actions is limited to x86 so if we wanted to add AArch64 wheels at some point we will probably still need Travis-CI for that. |
@grlee77 Yes, Travis-CI is well suited for that job. I have a repo with changes to build aarch64 wheels on Graviton2 instances: https://github.com/janaknat/scikit-image-wheels/blob/master/.travis.yml. Just waiting on scipy aarch64 wheels to land since there are issues with building them from source (dependencies and such). |
attn @jni: I think you are doing the upcoming 0.18 release?
It looks like this repository is still configured to upload to Rackspace, but as far as I am aware we no longer have free space with them. Several projects have moved over to staging wheels at multibuild-wheels-staging
Is this the approach the
scikit-image
team also wants to take?If so, I can create a TOKEN with the necessary permissions at multibuild-wheels-staging and then create corresponding environment variables on Travis and Appveyor. We then just have to make some minor changes to the scripts here (similar to the changes done for PyWavelets recently in MacPython/pywavelets-wheels#13).
An alternative approach using GitHub Actions instead was taken by the DIPY team in MacPython/dipy-wheels#5. In that case they did not have to create their own Token and were just able to reuse the "secrets" already stored for the
MacPython
organization. However, given thatscikit-image-wheels
is not under theMacPython
organization, I don't think the same will be true here.The text was updated successfully, but these errors were encountered: