Repository navigation
Request access for PyWavelets #75
Description
Activity
@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
pywaveletsnightly wheel for me to upload to create the package in the registry - Verify that I have added you to the
pywaveletsteam "Group" on https://anaconda.org/scientific-python-nightly-wheels - Verify that I have added the package
scientific-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!
Reacted by Jarrod Millman, Agriya Khetarpal and Ralf GommersDirect me to a
pywaveletsnightly wheel for me to upload to create the package in the registryHi! 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?)
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
pywaveletsnightly wheel for me to upload to create the package in the registryCould you grab a wheel from https://pypi.org/project/PyWavelets/#files for now? Any wheel from the 1.5.0 release will do here.
Reacted by Matthew FeickertHi! 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.
Reacted by Ralf GommersHi, @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!
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.)
Reacted by Agriya Khetarpal(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.dev0should be fine for PyWavelets.Reacted by Matthew FeickertThanks for the uploads! Looks like we're all set here. @agriyakhetarpal over to you for the nightlies CI:)
Reacted by Matthew FeickertThat 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.dev0should 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.The use of
+githashat https://anaconda.org/scientific-python-nightly-wheels/pandas/files is also fine in principle, nothing will go wrong with that.Reacted by Matthew FeickertThis 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 :)
(
pipfails to parse wheel files with a+in their names – this was the case with thematplotlibnightlies,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.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 :)
👍🏼
Reacted by Matthew FeickertCross posting PyWavelets/pywt#710 (comment): we now have wheels at https://anaconda.org/scientific-python-nightly-wheels/PyWavelets/files. Thank you, @matthewfeickert!
Reacted by Jarrod Millman and Matthew Feickert
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:
wasm32) wheels, which can be uploaded to the anaconda.org buckets I believe, but aren't allowed on PyPI/TestPyPI yet.