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.
