Request "python" organisation on PyPI (original) (raw)
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.
Any objections to asking for the https://pypi.org/org/python/ organisation, to use for the packages that are maintained under the https://github.com/python GitHub organisation?
This should make things easier for us to maintain, in addition to giving us the umbrella /org/python/ URL.
Some example candidates:
gpshead (Gregory P. Smith) May 5, 2023, 8:18pm 2
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.
hugovk (Hugo van Kemenade) May 31, 2023, 8:32pm 3
Sounds good, I’ll ask the steering council for a policy. Like the python org repo policy, it could include requiring 2FA.
(2FA will be required for “every account that maintains any project or organization on PyPI” by the end of the year, but why wait?)
hugovk (Hugo van Kemenade) September 4, 2023, 8:05pm 4
thomas (Thomas Wouters) December 4, 2023, 3:37pm 5
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.
CAM-Gerlach (C.A.M. Gerlach) December 4, 2023, 8:15pm 6
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?
hugovk (Hugo van Kemenade) December 4, 2023, 8:15pm 7
Thanks, yes, I agree with all this.
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.
hugovk (Hugo van Kemenade) December 6, 2023, 5:05pm 8
It already exists: https://pypi.org/org/psf/, currently only hosting psf/cachecontrol.
hugovk (Hugo van Kemenade)
December 6, 2023, 5:13pm 9
I’ve submitted requests for the two orgs:
hugovk (Hugo van Kemenade) November 5, 2024, 7:39pm 10
We now have the pypi.org/org/cpython/ and pypi.org/org/python/ organisations 
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.
encukou (Petr Viktorin) November 6, 2024, 7:45am 11
Now’s the time to decide what kind of repo should go in python and what should go in cpython. Start small, but look at the big picture :)
My thinking is that blurb & cherry-picker are cpython-specific, but python-docs-theme, used by PyPA or typing, might be better in python.
hugovk (Hugo van Kemenade) November 6, 2024, 8:59am 12
I don’t mind too much either way, but python-docs-theme README does point out
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.
hugovk (Hugo van Kemenade) November 6, 2024, 10:06pm 13
cherry-picker is now in pypi.org/org/cpython/ and I also gave @Mariatta the manager role for both orgs.
Next: let’s move blurb → cpython: python/blurb#33.
hugovk (Hugo van Kemenade) November 9, 2024, 10:37am 14
blurb is now also in pypi.org/org/cpython/.
Let’s decide about python-docs-theme: python/python-docs-theme#205.
hugovk (Hugo van Kemenade) December 14, 2024, 5:13pm 15
We decided on python for python-docs-theme, it’s pending addition.
Meanwhile pyperformance is now the first in pypi.org/org/python/ (re: python/pyperformance#370).
And here’s an issue to suggest adding tzdata to python: python/tzdata#84.
I made a project to track these: https://github.com/orgs/python/projects/53.
hugovk (Hugo van Kemenade) December 21, 2024, 11:54am 16
python-docs-theme and tzdata are both now in pypi.org/org/python/.
Here’s an issue for pyperf: psf/pyperf#211.
Are there any other packages to consider? If not then we’re more or less done, other than documenting the categorisation in the devguide.
hugovk (Hugo van Kemenade) January 10, 2025, 12:18pm 17
pyperf is now in pypi.org/org/python/.
And python/devguide#1484 is a PR to document the PyPI orgs policy in the devguide.