Request access for PyWavelets

[rgommers]

Hi all, it's be great to get access to https://anaconda.org/scientific-python-nightly-wheels/ for PyWavelets nightlies.

PyWavelets is a pretty-slow moving project with small wheels, so the extra load should be light. Two reasons why I'm asking for access:

1. PyWavelets is an optional dependency of scikit-image, which is already hosted here - and @jarrodmillman mentioned that it'd be good to have space for the dependency trees of the already-hosted projects (will immediately come in handy with the NumPy 2.0 rebuilds I suspect).
2. We're working on interactive docs and like to use PyWavelets as one of the first packages to have them, since it's small and easy to work on. For that we need Pyodide (wasm32) wheels, which can be uploaded to the anaconda.org buckets I believe, but aren't allowed on PyPI/TestPyPI yet.

[matthewfeickert]

@rgommers please complete the missing items from the checklist to get started.

• Create an account on Anaconda Cloud
• Reply here with the link to your account (https://anaconda.org/rgommers)
• Make a new Anaconda Cloud API token with permissions described in https://scientific-python.org/specs/spec-0004/#process-for-adding-new-projects

• Save the API token as a repo GitHub Actions secret named ANACONDA_ORG_UPLOAD_TOKEN
• Direct me (@matthewfeickert) to a pywavelets nightly wheel for me to upload to create the package in the registry
• Verify that I have added you to the pywavelets team "Group" on https://anaconda.org/scientific-python-nightly-wheels
• Verify that I have added the package scientific-python-nightly-wheels/pywavelets to the pywavelets team "Group"

If you'd also like to use the scientific/upload-nightly-action GitHub Action please check out the action repo's README. If you need to collect wheels from different CI jobs, consider creating a new GitHub Actions workflow with logic similar to matplotlib's or Awkward's.

If you have any questions please just ask here!

[agriyakhetarpal]

Direct me to a pywavelets nightly wheel for me to upload to create the package in the registry

Hi! I shall be helping out with this. We are currently building the WASM wheels on GitHub Actions itself and don't use other CI providers for that, so I can set up jobs at the earliest convenience for this with the use of the provided Action. We might need to figure out versioning for nightly wheels (perhaps through VCS or just a small helper script should be fine?)

[rgommers]

Thanks @matthewfeickert!

I've create the API token and added it to the repo, so those two actions can be checked off.

Direct me (@matthewfeickert) to a pywavelets nightly wheel for me to upload to create the package in the registry

Could you grab a wheel from https://pypi.org/project/PyWavelets/#files for now? Any wheel from the 1.5.0 release will do here.

[matthewfeickert]

Hi! I shall be helping out with this.

👋 Great @agriyakhetarpal. It would be good to have you have admin access to the PyWavelets group so can you please:

• Create an account on Anaconda Cloud
• Reply here with the link to your account

We might need to figure out versioning for nightly wheels (perhaps through VCS or just a small helper script should be fine?)

Yeah, VCS is always good, but if needed you can also just overwrite the previous wheels here (multiple projects currently do this).

Could you grab a wheel from https://pypi.org/project/PyWavelets/#files for now? Any wheel from the 1.5.0 release will do here.

@rgommers Done: https://anaconda.org/scientific-python-nightly-wheels/PyWavelets/files

You should be ready to go with uploading wheels now! I'll leave this open though until you have a succesful upload run with your CI.

[agriyakhetarpal]

Hi, @matthewfeickert, I created an account and here's the link: https://anaconda.org/agriyakhetarpal (I'm a bit surprised there's no 2FA available!).

Yeah, VCS is always good, but if needed you can also just overwrite the previous wheels here (multiple projects currently do this).

Sure, we had decided that we'll still prefer to get wheels uploaded once in 25 days in case no activity on the repository occurs; I can follow suit with what @rgommers has to suggest. Either way, appending a date or a hash to the version should be trivial.

Thank you for approving the request – we will add a comment here once the first iteration of the nightly wheels comes out!

[matthewfeickert]

I created an account and here's the link: https://anaconda.org/agriyakhetarpal

@agriyakhetarpal Thanks! I've added you to the pywavelets team "Group" (it is now you and @rgommers).

(I'm a bit surprised there's no 2FA available!).

Yes, me too. While Anaconda has been very generous with their storage resources, Anaconda Cloud is showing its age in general. :/

Sure, we had decided that we'll still prefer to get wheels uploaded once in 25 days in case no activity on the repository occurs; I can follow suit with what @rgommers has to suggest.

Yeah, you can always just overwrite the existing wheels with the same files.

Either way, appending a date or a hash to the version should be trivial.

Please do not do that. Even though these are nightly wheels please use valid PEP 440 names for all wheels uploaded to https://anaconda.org/scientific-python-nightly-wheels/. (Including dates and hashes are both invalid)

(Sorry, I accidentally edited your post while replying to it as I started typing in the wrong text box after quoting it. I think I restored it to the original post though.)

[rgommers]

(Including dates and hashes are both invalid)

That is not true I believe, you can include them after + as local version identifiers: https://packaging.python.org/en/latest/specifications/version-specifiers/#local-version-identifiers.

That said, I don't really like this habit of dynamically changing the version anymore. I have a strong preference for purely static metadata; 1.x.y.dev0 should be fine for PyWavelets.

[rgommers]

Thanks for the uploads! Looks like we're all set here. @agriyakhetarpal over to you for the nightlies CI:)

[matthewfeickert]

That is not true I believe, you can include them after + as local version identifiers: https://packaging.python.org/en/latest/specifications/version-specifiers/#local-version-identifiers.

Isn't the whole point of local version identifiers that they aren't distributed for public use? I'm asking here out of genuine curiosity / ignorance, because if not then I've grossly misunderstood them.

That said, I don't really like this habit of dynamically changing the version anymore. I have a strong preference for purely static metadata; 1.x.y.dev0 should be fine for PyWavelets.

👍

[rgommers]

Isn't the whole point of local version identifiers that they aren't distributed for public use? I'm asking here out of genuine curiosity / ignorance, because if not then I've grossly misunderstood them.

Kinda but not really. They are not allowed on PyPI, and PEP 440 says so explicitly. So that matches what you are saying. However, it is a case of "PyPI and Python packaging are too limited". Here is an example of PyTorch using +cpu.... for distinguishing between CPU-only and CUDA-enabled builds: https://download.pytorch.org/whl/torch/ (that's the public index server). There is no other way to distinguish those builds.

The use of +githash at https://anaconda.org/scientific-python-nightly-wheels/pandas/files is also fine in principle, nothing will go wrong with that.