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
{{ message }}
Repository navigation
Request for access for awkward, awkward-cpp, and uproot #29
We (over at scikit-hep) maintain several packages that would benefit from nightlies. To begin with, I'd like to request access for the following projects:
Following up on the discussions started in #20 (comment) I think that further approval / review requires people with org level admin powers, so tagging @tupui, @stefanv, and @jarrodmillman. (I think there may be others, but I don't know.)
(Also yay! I love these projects and think it would be great to have their nightlies up too.)
I had also once asked if astropy should moved its nightlies to SP. (We already host it somewhere else.) The motivation is that downstream can pull the whole stack from the same index URL. But if not, also no big deal. I guess it depends on the goal and scope of SP hosting. cc @astrofrog@Cadair
@agoose77 as I know that awkward uses hatchling, if your request is approved just a heads up that you might run into anaconda/anaconda-client#676. I will tag Ofek there to see if he has any suggestions for the anaconda-client team.
We probably want to add some more guidance about what we can include, but we can sort things out as we go. I am busy this weekend, but can look into this next week.
We probably want to add some more guidance about what we can include, but we can sort things out as we go.
I really would prefer if the guidelines are figured out first than starting to add random packages (==non core, and core dependencies), then ending up to need to say no for others later when we run into technical limitations, e.g. not enough space, etc.
That guideline could be very generic, that e.g. specific things from the domain stack could use the same space, etc, but I definitely see the value of figuring it out first rather than when a handful of packages are already there.
I'll let the Awkward dev team decide if they want to keep this Issue open for future discussion, of if they are content with this solution for the long term, in which case they can close it. 👍
Here's a somewhat radical proposal: include everyone who will find this service useful. Once we outgrow our space, we'll have to tell new projects "no" until we figure out a solution. The solution may be as easy as hosting our own conda server, for which we already have server capacity.
Reacted by Martin Fleischmann, Jarrod Millman, Matthew Feickert and Eric Prestat
Reacted by Matthew Feickert, Agriya Khetarpal and Jarrod Millman
include everyone who will find this service useful
I don't find it that radical. As far as I understood this initiative when we discussed it during the summit in Seattle last year, this was the intention. I wasn't involved very much in subsequent discussions but if there's a way of providing this service to the whole ecosystem, rather than a selection of packages based on unclear criteria and essentially a feeling of a package importance, let's try to do that.
Reacted by Jarrod Millman, Matthew Feickert and Eric Prestat
@stefanv@martinfleis I am +1 on this. I would be very happy to accept the requests that are already open in this Issue and Issues #45, #50, and #51, but to have this be a decision that is easily understood in the future can the following happen (in the very near future)?
Have the @scientific-python/spec-steering-committee agree on moving forward with this proposal in the very near future
@stefanv as you are a member of the @scientific-python/spec-steering-committee can you comment on how soon you think a discussion could take place? I'm not sure how often async discussions happen, but I'd be keen to move on this.
The solution may be as easy as hosting our own conda server, for which we already have server capacity.
@stefanv Can you comment (over on #30) on how much server space Scientific Python realistically has? If more than 30 GB could be given to storage of wheels then I would be interested in helping to get this setup even if this is just as a test instance. I'm in general +1 on controlling infrastructure, but if Scientific Python's grant funds can be spent on things other than server costs I'm also +1 on taking advantage of Anaconda's generosity to open source.
If you'd also like to use the scientific/upload-nightly-action GitHub Action that this repository provides please check out this 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.
Activity
matthewfeickert commentedon Aug 4, 2023
Following up on the discussions started in #20 (comment) I think that further approval / review requires people with org level admin powers, so tagging @tupui, @stefanv, and @jarrodmillman. (I think there may be others, but I don't know.)
(Also yay! I love these projects and think it would be great to have their nightlies up too.)
pllim commentedon Aug 4, 2023
I had also once asked if
astropyshould moved its nightlies to SP. (We already host it somewhere else.) The motivation is that downstream can pull the whole stack from the same index URL. But if not, also no big deal. I guess it depends on the goal and scope of SP hosting. cc @astrofrog @Cadairmatthewfeickert commentedon Aug 4, 2023
@pllim to avoid crossover of discussions can I ask that you make a request in a separate Issue like Issue #20 and Issue #29?
upload-nightly-action/README.md
Lines 39 to 45 in a2ba178
(We don't have this super formalized at the moment, but c.f. #20 (comment) for how we might make it so in the future.)
matthewfeickert commentedon Aug 4, 2023
@agoose77 as I know that
awkwarduseshatchling, if your request is approved just a heads up that you might run into anaconda/anaconda-client#676. I will tag Ofek there to see if he has any suggestions for theanaconda-clientteam.jarrodmillman commentedon Aug 4, 2023
I am +1 for adding
awkwardawkward-cppuprootastropynightliesWe probably want to add some more guidance about what we can include, but we can sort things out as we go. I am busy this weekend, but can look into this next week.
bsipocz commentedon Aug 4, 2023
I really would prefer if the guidelines are figured out first than starting to add random packages (==non core, and core dependencies), then ending up to need to say no for others later when we run into technical limitations, e.g. not enough space, etc.
That guideline could be very generic, that e.g. specific things from the domain stack could use the same space, etc, but I definitely see the value of figuring it out first rather than when a handful of packages are already there.
matthewfeickert commentedon Feb 8, 2024
To mitigate this I've made a
scikit-hep-nightly-wheelsAnaconda Cloud organization which with scikit-hep/awkward#3012 is now taking care of nightly wheels forawkwardandawkward-cpp(contingent on anaconda/anaconda-client#702 being resolved).I'll let the Awkward dev team decide if they want to keep this Issue open for future discussion, of if they are content with this solution for the long term, in which case they can close it. 👍
stefanv commentedon Feb 9, 2024
Here's a somewhat radical proposal: include everyone who will find this service useful. Once we outgrow our space, we'll have to tell new projects "no" until we figure out a solution. The solution may be as easy as hosting our own conda server, for which we already have server capacity.
martinfleis commentedon Feb 11, 2024
I don't find it that radical. As far as I understood this initiative when we discussed it during the summit in Seattle last year, this was the intention. I wasn't involved very much in subsequent discussions but if there's a way of providing this service to the whole ecosystem, rather than a selection of packages based on unclear criteria and essentially a feeling of a package importance, let's try to do that.
matthewfeickert commentedon Feb 11, 2024
@stefanv @martinfleis I am +1 on this. I would be very happy to accept the requests that are already open in this Issue and Issues #45, #50, and #51, but to have this be a decision that is easily understood in the future can the following happen (in the very near future)?
@stefanv as you are a member of the @scientific-python/spec-steering-committee can you comment on how soon you think a discussion could take place? I'm not sure how often async discussions happen, but I'd be keen to move on this.
@stefanv Can you comment (over on #30) on how much server space Scientific Python realistically has? If more than 30 GB could be given to storage of wheels then I would be interested in helping to get this setup even if this is just as a test instance. I'm in general +1 on controlling infrastructure, but if Scientific Python's grant funds can be spent on things other than server costs I'm also +1 on taking advantage of Anaconda's generosity to open source.
matthewfeickert commentedon Feb 22, 2024
Seems storage isn't really an issue at all anymore given #30 (comment). 👍
matthewfeickert commentedon Feb 22, 2024
@agoose77 @jpivarski Good news, we have the approval (#30 (comment)) to add
awkward-cpp,awkward, anduprootto the nightly wheels Anaconda Cloud org https://anaconda.org/scientific-python-nightly-wheels/ !To get started on this can @agoose77 and @jpivarski please do the following:
Steps to gain upload access to https://anaconda.org/scientific-python-nightly-wheels/
(@jpivarski already did these steps in scikit-hep/awkward#3012 for https://anaconda.org/scikit-hep-nightly-wheels/ so he doesn't need to do them again, and the token he made is still good here. 👍 Though @agoose77 if you want upload permissions/responsibility then please make an Aanconda Cloud account too.)
Create an account on Anaconda CloudReply here with the link to your accountMake a new Anaconda Cloud API token with permissions described in https://scientific-python.org/specs/spec-0004/#process-for-adding-new-projectsSave the API token as a repo GitHub Actions secret namedANACONDA_ORG_UPLOAD_TOKENawkward-cppnightly wheel for me to upload to create the package in the registryawkwardnightly wheel for me to upload to create the package in the registryuprootnightly wheel for me to upload to create the package in the registryAwkwardandUprootteam "Groups" on https://anaconda.org/scientific-python-nightly-wheelsscientific-python-nightly-wheels/awkward-cppto theAwkwardteam "Group"scientific-python-nightly-wheels/awkwardto theAwkwardteam "Group"scientific-python-nightly-wheels/uprootto theUprootteam "Group"If you'd also like to use the
scientific/upload-nightly-actionGitHub Action that this repository provides please check out this 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!