Request for access for awkward, awkward-cpp, and uproot

[agoose77]

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:

• awkward
• awkward-cpp
• uproot

Thanks all!

[matthewfeickert]

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]

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

[matthewfeickert]

@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

	# Access
	To request access to the repository, please open an issue on [this action's
	repository](https://github.com/scientific-python/upload-nightly-action). You can
	then generate a token at `https://anaconda.org/scientific-python-nightly-wheels/settings/access`
	with permissions to _Allow write access to the API site_ and _Allow uploads to Standard Python repositories_,
	and add the token as a secret to your GitHub repository.

(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]

@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.

[jarrodmillman]

I am +1 for adding

• awkward
• awkward-cpp
• uproot
• astropy nightlies

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.

[bsipocz]

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.

[matthewfeickert]

To mitigate this I've made a scikit-hep-nightly-wheels Anaconda Cloud organization which with scikit-hep/awkward#3012 is now taking care of nightly wheels for awkward and awkward-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]

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]

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.

[matthewfeickert]

@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
• Have the @scientific-python/spec-steering-committee advise on what a future policy would be (this is Establish guideline for packages that can upload to the scientific-python nightly channel #30 (comment)) so that when space limits are hit there is a clear transition plan.

@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.

[matthewfeickert]

The solution may be as easy as hosting our own conda server, for which we already have server capacity.

Seems storage isn't really an issue at all anymore given #30 (comment). 👍

[matthewfeickert]

@agoose77 @jpivarski Good news, we have the approval (#30 (comment)) to add awkward-cpp, awkward, and uproot to 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 Cloud
• Reply here with the link to your account
• 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 an:
  • awkward-cpp nightly wheel for me to upload to create the package in the registry
  • awkward nightly wheel for me to upload to create the package in the registry
  • uproot nightly wheel for me to upload to create the package in the registry
• Verify that I have added you to the Awkward and Uproot team "Groups" on https://anaconda.org/scientific-python-nightly-wheels
• Verify that I have added the package:
  • scientific-python-nightly-wheels/awkward-cpp to the Awkward team "Group"
  • scientific-python-nightly-wheels/awkward to the Awkward team "Group"
  • scientific-python-nightly-wheels/uproot to the Uproot team "Group"

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.

If you have any questions please just ask here!