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
@skoudoro has this been discussed with the SPEC Steering Committee? Currently I believe that only packages that are defined as "core" are being given upload permissions to the channel (c.f. #30 (comment) and Issue #29).
No, I did not know that I need to do a request to the steering commitee first
Currently I believe that only packages that are defined as "core" are being given upload permissions to the channel (c.f. #30 (comment) and Issue #29).
ok, thank you for letting me know. I believed it was for all scientific package and an alternative to the previous one https://anaconda.org/scipy-wheels-nightly/ where we had our nightly build.
@skoudoro Are there many packages that depend on a DiPy wheel for testing? That may be motivation to include it.
I may not be up to speed with the recent discussions but original idea was not limited to core projects. We wanted to replace the scipy nightly channel so any package that is compiled and used by a wider community could be included.
While we should clarify the scope of the SPEC, we should also be pragmatic and flexible and do whatever is useful to the community. @skoudoro So you know, your request is totally valid, and it falls on us to clarify the parameters here.
FWIW, re: the term "core projects": it was a useful idea to get the project going, but we're trying to move away from it and towards a notion of "every project actively participating in the process and conversation". The idea was always to involve the wider community, not to use it for exclusion.
Let's also get some input from some of the other SPEC authors, who will be more familiar with the conversation; @bsipocz@jarrodmillman et al. Note that it's thanksgiving in the US, so we may only hear back next week.
@skoudoro I'm going to leave this open so that (and until) the SPEC authors can respond here (unless @bsipocz and @jarrodmillman want to continue this discussion where it originally started in Issue #29 or was moved to in Issue #30).
The main issue is how much space anaconda is willing to give us. I asked a friend whether they could ask for more space since they know people at anaconda. I will make another request and see if we can get more space.
Modulo space limits (I didn't realise there was a limit) I'd say that in general all packages that have a track record of being maintained and used should be eligible.
Verify that I have added the package scientific-python-nightly-wheels/dipy to the dipy team "Group"
As you're already using the scientific-python/upload-nightly-action GitHub Action the only thing that you need to do is to make sure that you have a personal API key, and then make a PR to change where the action is uploading by removing the dipy org argument. 👍
Activity
matthewfeickert commentedon Nov 22, 2023
@skoudoro has this been discussed with the SPEC Steering Committee? Currently I believe that only packages that are defined as "core" are being given upload permissions to the channel (c.f. #30 (comment) and Issue #29).
stefanv commentedon Nov 22, 2023
@skoudoro Are there many packages that depend on a DiPy wheel for testing? That may be motivation to include it.
skoudoro commentedon Nov 22, 2023
No, I did not know that I need to do a request to the steering commitee first
ok, thank you for letting me know. I believed it was for all scientific package and an alternative to the previous one https://anaconda.org/scipy-wheels-nightly/ where we had our nightly build.
Not sure, about that, when I look at the download of our previous nightly build repo, it seems only few packages were using it: https://anaconda.org/scipy-wheels-nightly/dipy/files.
skoudoro commentedon Nov 22, 2023
Thank you @matthewfeickert, I will read the thread.
Also, what do you recommend as an alternative for now @matthewfeickert and @stefanv ?
martinfleis commentedon Nov 22, 2023
I may not be up to speed with the recent discussions but original idea was not limited to core projects. We wanted to replace the scipy nightly channel so any package that is compiled and used by a wider community could be included.
stefanv commentedon Nov 22, 2023
While we should clarify the scope of the SPEC, we should also be pragmatic and flexible and do whatever is useful to the community. @skoudoro So you know, your request is totally valid, and it falls on us to clarify the parameters here.
FWIW, re: the term "core projects": it was a useful idea to get the project going, but we're trying to move away from it and towards a notion of "every project actively participating in the process and conversation". The idea was always to involve the wider community, not to use it for exclusion.
Let's also get some input from some of the other SPEC authors, who will be more familiar with the conversation; @bsipocz @jarrodmillman et al. Note that it's thanksgiving in the US, so we may only hear back next week.
skoudoro commentedon Nov 22, 2023
No worries and thank you for clarifying. I understand also the anaconda space challenge.
For now, I will go ahead and use github as a nightly wheels storage like cython project.
I am closing this issue since I feel it is a duplicate of #29 and #30.
Just keep me updated if there is some progress concerning this point.
Thank you all and Happy thanksgiving week!
matthewfeickert commentedon Nov 22, 2023
@skoudoro I'm going to leave this open so that (and until) the SPEC authors can respond here (unless @bsipocz and @jarrodmillman want to continue this discussion where it originally started in Issue #29 or was moved to in Issue #30).
jarrodmillman commentedon Nov 23, 2023
The main issue is how much space anaconda is willing to give us. I asked a friend whether they could ask for more space since they know people at anaconda. I will make another request and see if we can get more space.
betatim commentedon Nov 23, 2023
Modulo space limits (I didn't realise there was a limit) I'd say that in general all packages that have a track record of being maintained and used should be eligible.
jarrodmillman commentedon Nov 23, 2023
The space needs of packages varies a lot. For example, openblas-libs is using 2.4GB, while ipython and networkx combined use less than 3MB.
matthewfeickert commentedon Feb 23, 2024
@skoudoro Good news, we have the approval (#30 (comment)) to add
dipyto the nightly wheels Anaconda Cloud org https://anaconda.org/scientific-python-nightly-wheels/ !To get started on this can you please do the following:
Steps to gain upload access to https://anaconda.org/scientific-python-nightly-wheels/
dipycurrently has namedANACONDA_NIGHTLY_TOKENdipynightly wheel for me to upload to create the package in the registrydipyteam "Group" on https://anaconda.org/scientific-python-nightly-wheelsscientific-python-nightly-wheels/dipyto thedipyteam "Group"As you're already using the
scientific-python/upload-nightly-actionGitHub Action the only thing that you need to do is to make sure that you have a personal API key, and then make a PR to change where the action is uploading by removing thedipyorg argument. 👍If you have any questions please just ask here!
skoudoro commentedon Feb 23, 2024
That's a great news! thank you for following up with that!
I will do it a bit later today and keep you updated.
Thanks!
skoudoro commentedon Mar 25, 2024
all good, closing