PyPy wheels and moving off rackspace
Closed this issue · 17 comments
As per matthew-brett/multibuild#304, projects should not upload to rackspace since this is no longer free. Over at numpy-wheels, we chose to use anaconda.org for staging and weekly builds. Cython chose to upload them to github as release packages. One advantage to using a shared location is that any of the wheels in that location can be installed with a single -i https://pypi.anaconda.org/scipy-wheels-nightly/simple argument to pip.
If you choose the anaconda route, I can give an admin rights to the anaconda staging areas, and help you do something like the numpy-wheels upload code.
If you choose the github route, here is what cython did to upload there
In any case, it would be nice to provide PyPy wheels for linux64, macOS, win32 and aarch64 since kiwisolver is a dependency of matplotlib and people have some trouble building it.
Regarding PyPy I opened nucleic/kiwi#84 to first start running tests on PyPy on Travis. The first build fails due to missing Py_RETURN_NOTIMPLEMENTED. This macro has been added (see https://bitbucket.org/pypy/pypy/commits/17c92b183a23) but is not yet available on Travis version, and it seems there is no PyPy build for ARM. Any advice regarding this ? Miniconda maybe ?
As for the wheels I did not see 304 but I am fine uploading the wheels in a different place. Anaconda seems fine since kiwi is mostly linked to Matplotlib.
@mattip Can you give me some access to Anaconda so that I modify those build scripts ? Also could I also upload the other projects I maintain (atom and enaml) ?
Also do you have an example of project building wheels for PyPy ? (In particular since Travis only has an old pypy).
I think it would be better to use github releases for atom and enaml, since they are not dependencies on the scientific python stack like the other projects on the anaconda staging areas. The reason to use anaconda is then one can test the latest versions there with pip install -i https://pypi.anaconda.org/multibuild-wheels-staging/simple
Either you need to create an account on anaconda.org or give me rights to this repo so I can access the settings and add a "secret"
Correct me if my assertion about atom and enaml is incorrect
Also do you have an example of project building wheels for PyPy ?
Here is what numpy-wheels does. Unfortunately it only seems to support linux64 right now.
As you saw, azure/github actions support pypy out-of-the-box but you use appveyor for windows so I am not sure what the best way forward is there.
I have no issue switching to github actions (I already use it for most of my projects). I will need Travis for aarch stuff but that is all. I do have an anaconda.org account how should I proceed then ?
I sent you a message
@matthew-brett Could you give me access to appveyor config or suggest a way to migrate away from it ?
I figured it out, no need for me to get access.
The branch 1.3.0 implement the switch to conda but I am seeing a weird error on appveyor and on macOS for Python 3.9 any help is welcome, I have a bunch of people that want wheels for 3.9 as soon as possible.
@matthew-brett actually for Appveyor the issue is that I cannot properly encode the token because I do not have access to the appveyor account. Could you give me access please ?
You might have better luck if you update multibuild to the latest devel branch HEAD ec386efaa9e6
I updated yesterday night. The Appveyor issue is that I can decode a secret only of it was encoded by a member of the Appveyor org. Travis on macos is plainly weird. I will try updating again.
I updated yesterday night.
I don't see a PR for the multbuild update. Is that somewhere else?
I can't do much about appveyor other than encourage PR gh-10 to go through. The advantages of github actions are
- you get the token automatically as part of the MacPython organization
- permissions are the same as the permissions for the repo
- you get 6 hours of build time, which was critical for openblas-libs but may not be important to you.
The PR might need to start with someone creating a dummy github actions workflow file to get things going: an admin should click on the "Actions" tab at the top, then under Simple Actions -> Set up this Workflow. Once that is merged it tells github that this repo uses github actions. You (or more to the point @thomasjpfan) can go back to the PR and iterate on it, the action should run.
I typically only build releases and never updated the master of this repo. The branch v1.3.0 contains the proper changes. I can set up github actions but I hoped to spend less time on this than I already did. Thanks for your help.
After much suffering this now done. If Github adds support for ARM we will be able to remove Travis. Thanks for your help @mattip