Jupyter PyPI Organization
blink1073 opened this issue · 9 comments
FYI, we now have a "Project Jupyter" PyPI organization. I'm planning to come to the second half of the May 2nd security call to discuss strategy around the account. For now, I have added EC members as owners, and created JupyterLab, JupyterHub, IPython, and Jupyter Server teams. As an experiment, I added @fcollonval to the JupyterLab team and migrated hatch-jupyter-builder to be under the Jupyter org and managed by that team. Here's how it looks publicly:
@blink1073 this is great news, I've been hoping for a way to manage access to PyPI and other package repositories similar to how we manage GitHub access. Looking forward to discussing it with you.
Here's a general question: should we have one PyPI organization for jupyter and teams for our different groups, or have more orgs that match our general organizational practice (e.g. should we have a jupyterhub org or just a jupyterhub team)? It's not clear to me what the right choice is, yet.
To me, this is offering the feature that I wish we had on GitHub: a single public-facing and single managed top-level entity, delegating to the appropriate teams.
To me, this is offering the feature that I wish we had on GitHub: a single public-facing and single managed top-level entity, delegating to the appropriate teams.
I agree with this perspective. I think we can do this in a way that doesn't frustrate any of the Subprojects, like JupyterHub, so we will avoid the current GitHub scenario where we're tracking roles across orgs.
This also ties to a larger topic of at least tracking who has what roles for various Jupyter resources that we discussed in the previous Security call. GitHub and PyPI are both high priorities for this. I'd like to touch on this very briefly at the next SSC call to raise the topic. Then at the Security call on Tuesday we can draft a short implementation proposal to discuss with the SSC and others, starting a JupyterCon.
To get more of the idea out of my head and written down somewhere, here's a rough take:
- The primary goal is for Project Jupyter to know who has privileged access (e.g., owner, admin, manager, etc.) to critical resources, like GitHub or PyPI.
- We should maintain a list of these resources (see those previous Security meeting notes above) and those roles.
- Agree on private location to track privileged roles across Jupyter resources. We have a separate private GitHub repo for similar content, I would start with just a Markdown file with tables for each resource. We would begin with tracking who is an owner or admin for the GitHub organizations and within PyPI.
- For PyPI initially, and other package repositories later, agree on how roles for the Jupyter organization and its teams would be managed. This could be a mapping from the GitHub roles, or Subprojects could decide how they assign team managers.
- Document who to ask for help, both publicly and privately. Some of the information about owners, maintainers, etc., may already be public, so we can point to that.
I'll +1 having a single org for all reasons mentioned above.
Happy with a single org! We can always create more if we find they are needed. Much easier than going the other way.
I started looking at adding folks to the jupyterhub team, and I don't have permission, even as a manager because only owners of the Jupyter org can add any members to the org, and only members of the org can be added to teams. As a result, any time a team wants to add a member, it will bottleneck on an owner, because teams don't have delegated management of their own membership. This isn't the biggest deal, but for efficiency's sake I think at least one member of each team should be an owner on the PyPI org.
We are switching to it for JupyterLab packages. In addition to the pain pointed out by Min, I see the following problem too:
Team members get an homogeneous role on a package. Therefore, if a team is added to a package as maintainer, it losts the ability to yank a release or set up a trusted publisher for example. So I would recommend that every project get two teams <subprobjects>-owners and <subprojects>-maintainers. So that they can correctly manage their packages.
An alternative is to get only the owners team with all packages set up to use the trusted publisher mechanism (that removes the need for maintainers).