One of the big announcements at PyCon US was organisation accounts on PyPI:
Organizations on PyPI are self-managed teams, with their own exclusive branded web addresses. Our goal is to make PyPI easier to use for large community projects, organizations, or companies who manage multiple sub-teams and multiple packages. We’re making organizations available to community projects for free, forever, and to corporate projects for a small fee.
We should do this, but we need to not blindly put things in it on a whim because they exist elsewhere under that label. Our github organization has things in it that don’t belong there and only live there for historical reasons. We should be as narrow as our latest steering council decided New `python` organization repository policy policy or even narrower when adding things to a PyPI org.
Yes, the SC thinks this is a good idea. We should probably take both the ‘python’ and the ‘cpython’ org names. As a general policy on which is used for what, here’s what we have in mind:
cpython: for development tools that are tied fairly closely to CPython development. This could for example include blurb and cherry-picker. Users generally shouldn’t have to care except for developing CPython itself (although that doesn’t mean the tools necessarily have to be unusable for anyone else).
python: for general-audience projects that are maintained the Python Core Devs. An example for this category would be tzdata.
In both cases it should only be used for packages that are ostensibly collectively maintained by the Core Developers (even if only one or two people are actively doing so), as opposed to packages that are maintained by people who also happen to be Core Developers but are publishing the package independently. The python and cpython orgs would put the responsibility and authority on the Core Developers as a whole, and we want to make sure we reflect those expectations in the policy.
That said, the SC doesn’t have a lot of experience with PyPI orgs, so we want to make sure this policy makes sense to the Core Devs it would affect, as well as PyPI maintainers and potential users. Please let us know what you think.
That seems to generally make sense to me, after having considered it. “Official” backports/forward ports maintained by the core devs collectively could also be including in python, I would think?
Also, would there be a psf org for projects that are officially under the PSF umbrella on GitHub, or similar?
I could make a start and put in the application for those orgs with PyPA. I know they’ve currently got a large backlog in approving orgs. We might be able to get approved more quickly, but also we’re not in a rush.
That said, the SC doesn’t have a lot of experience with PyPI orgs, so we want to make sure this policy makes sense to the Core Devs it would affect, as well as PyPI maintainers and potential users. Please let us know what you think.
Yes, I would suggest we start with just one or two packages, so we gain experience with it. We should absolutely make sure the current core dev maintainers of each package are on board, and I think we can do this via issues in their repos before being added to any org.
As PyPI organisations are very new to us, let’s start small so we can gain experience as we go along, especially around the various roles; see the matrix in the docs. Ideas welcome on this.
Right now, Ee and I have the owner role for both orgs. Perhaps we can create a team for each project and add interested core team members as maintainers or owners. Although we’re already using Trusted Publishers which takes care of uploading for us.
I suggest starting with moving one of blurb, cherry-picker or python-docs-theme into the cpython org. I’ll open an issue in the relevant repo.
Note that when adopting this theme, you’re also borrowing an element of the trust and credibility established by the CPython core developers over the years. That’s fine, and you’re welcome to do so for other Python community projects if you so choose, but please keep in mind that in doing so you’re also choosing to accept some of the responsibility for maintaining that collective trust.
I think that tips it more towards the cpython side in the following categorisation?
Anyway, let’s start with more obvious ones, like cherry-picker → cpython: python/cherry-picker#142.
