Skip to content

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

Closed

Description

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

Activity

  1. matthewfeickert commented on Aug 4, 2023

    @matthewfeickert
    Member

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

  2. pllim commented on Aug 4, 2023

    @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

  3. matthewfeickert commented on Aug 4, 2023

    @matthewfeickert
    Member

    @pllim to avoid crossover of discussions can I ask that you make a request in a separate Issue like Issue #20 and Issue #29?

    # 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.)

  4. matthewfeickert commented on Aug 4, 2023

    @matthewfeickert
    Member

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

  5. jarrodmillman commented on Aug 4, 2023

    @jarrodmillman
    Member

    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.

  6. bsipocz commented on Aug 4, 2023

    @bsipocz
    Member

    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.

  7. matthewfeickert commented on Feb 8, 2024

    @matthewfeickert
    Member

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

  8. stefanv commented on Feb 9, 2024

    @stefanv
    Member

    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.

  9. martinfleis commented on Feb 11, 2024

    @martinfleis
    Member

    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.

  10. matthewfeickert commented on Feb 11, 2024

    @matthewfeickert
    Member

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

    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.

  11. matthewfeickert commented on Feb 22, 2024

    @matthewfeickert
    Member

    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). 👍

  12. matthewfeickert commented on Feb 22, 2024

    @matthewfeickert
    Member

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

    image

    • 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:

    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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions