switch from Rackspace uploads to Anaconda.org

[grlee77]

Hi @rgommers

I am trying to update this repo so that PyWavelets can upload staging wheels to anaconda.org instead of Rackspace. I don't think we need chron job uploads, but just want to upload when PRs here are merged.

@mattip: I saw that you recently helped the Astropy folks make the corresponding changes and would appreciate if you can provide feedback here as well, specifically on what scope is needed for the Anaconda token at multibuild-wheels-staging.

Here are the steps I have taken:

• Log into anaconda.org and create a new PYWAVELETS_STAGING_UPLOAD_TOKEN under the multibuild-wheels-staging organization. What are the appropriate "Scopes" to select when creating this token? I had selected "Allow all operations on Conda repositories", but am not sure that is correct. I will revoke it and regenerate as needed.

• create PYWAVELETS_STAGING_UPLOAD_TOKEN environment variables corresponding to the token at Travis-CI (at https://travis-ci.org/github/MacPython/pywavelets-wheels/settings) and Appveyor (at https://ci.appveyor.com/project/PyWavelets/pywavelets-wheels/settings/environment).

• update the YAML scripts as in this PR to upload to anaconda.org via anaconda-client using the token

[mattip]

So far so good, but you still haven't gotten to the point where the upload is triggered: travis didn't run and appveyor failed to run the tests.

You might be interested in using github actions as in the dipy PR since they are better integrated with github, and provide an easy path for x86 based systems (mac, windows, linux).

As for scope of the tokens I am not sure. It would be nice to figure out the minimum requirements and put them on some documentation somewhere.

[grlee77]

You might be interested in using github actions as in the dipy PR since they are better integrated with github, and provide an easy path for x86 based systems (mac, windows, linux).

I did see that recently, but hadn't taken a close look yet. There is a current request to add AArch64 wheels here. Would you recommend trying to build all x86 stuff via GitHub actions, but keep a Travis-CI case similar to this PR but with changes from #12 for AArch64? For now, I thought it might just be simpler to make these few modifications to the existing approach, but can reconsider as needed.

[grlee77]

@tylerjereddy, when you configured SciPy wheels to move the uploads to anaconda.org, do you remember what scope(s) you enabled for the token at https://anaconda.org/multibuild-wheels-staging? There is a long list of options and I am unsure what the minimal scope needed to be able to upload wheels is. I could just enable "all", but thought a more minimal scope would be preferable from a security standpoint.

[grlee77]

Appveyor pytest failures are apparently due to a env configuration option in our pytest.ini. We can install pytest-env here to avoid there error for now, but I have made a PR upstream to just remove this option: PyWavelets/pywt#569

[tylerjereddy]

@grlee77

do you remember what scope(s) you enabled for the token at https://anaconda.org/multibuild-wheels-staging

Yes, I followed the token creation instructions provided by Olivier Grisel to the SciPy mailing list on Feb. 12/2020, stating two things to activate:

• Write access to API
• Upload pypi packages

[grlee77]

Thank you @mattip and @tylerjereddy for your assistance. All wheels are now showing up at multibuild-wheels-staging!

For the record, the only two "scopes" I selected when creating the final Token were the ones suggested:

• "Allow write access to the API site"
• "Allow uploads to PyPI repositories"