You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
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.
Reacted by Stefan van der Walt, Agriya Khetarpal, Brigitta Sipőcz, Jarrod Millman and Matthew Feickert
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?)
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!
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.
(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.)
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.
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.
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.
This is slightly out of context, but I have faced problems with installing wheel files that contain local version identifiers at an earlier date (pip fails to parse wheel files with a + in their names – this was the case with the matplotlib nightlies, but scipy nightlies worked fine). Is that intended behaviour or is installing with --index-url or --extra-index-url the only intended pathway to grab a wheel?
I have set the above linked PR (PyWavelets/pywt#710) to close this issue upon merging – please let me know if that should be removed :)
Activity
matthewfeickert commentedon Mar 8, 2024
@rgommers please complete the missing items from the checklist to get started.
ANACONDA_ORG_UPLOAD_TOKENpywaveletsnightly wheel for me to upload to create the package in the registrypywaveletsteam "Group" on https://anaconda.org/scientific-python-nightly-wheelsscientific-python-nightly-wheels/pywaveletsto thepywaveletsteam "Group"If you'd also like to use the
scientific/upload-nightly-actionGitHub 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 tomatplotlib's orAwkward's.If you have any questions please just ask here!
agriyakhetarpal commentedon Mar 8, 2024
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 commentedon Mar 8, 2024
Thanks @matthewfeickert!
I've create the API token and added it to the repo, so those two actions can be checked off.
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 commentedon Mar 8, 2024
👋 Great @agriyakhetarpal. It would be good to have you have admin access to the PyWavelets group so can you please:
Yeah, VCS is always good, but if needed you can also just overwrite the previous wheels here (multiple projects currently do this).
@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 commentedon Mar 9, 2024
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!).
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 commentedon Mar 10, 2024
@agriyakhetarpal Thanks! I've added you to the pywavelets team "Group" (it is now you and @rgommers).
Yes, me too. While Anaconda has been very generous with their storage resources, Anaconda Cloud is showing its age in general. :/
Yeah, you can always just overwrite the existing wheels with the same files.
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 commentedon Mar 10, 2024
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.dev0should be fine for PyWavelets.rgommers commentedon Mar 10, 2024
Thanks for the uploads! Looks like we're all set here. @agriyakhetarpal over to you for the nightlies CI:)
matthewfeickert commentedon Mar 10, 2024
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.
👍
rgommers commentedon Mar 11, 2024
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
+githashat https://anaconda.org/scientific-python-nightly-wheels/pandas/files is also fine in principle, nothing will go wrong with that.agriyakhetarpal commentedon Mar 11, 2024
This is slightly out of context, but I have faced problems with installing wheel files that contain local version identifiers at an earlier date (
pipfails to parse wheel files with a+in their names – this was the case with thematplotlibnightlies, butscipynightlies worked fine). Is that intended behaviour or is installing with--index-urlor--extra-index-urlthe only intended pathway to grab a wheel?I have set the above linked PR (PyWavelets/pywt#710) to close this issue upon merging – please let me know if that should be removed :)
rgommers commentedon Mar 11, 2024
Then it probably wasn't a valid PEP 440 name I think. It's easy to get that wrong. If it was a valid name,
pipshould not choke on it.👍🏼
agriyakhetarpal commentedon Mar 12, 2024
Cross posting PyWavelets/pywt#710 (comment): we now have wheels at https://anaconda.org/scientific-python-nightly-wheels/PyWavelets/files. Thank you, @matthewfeickert!