As part of improving the virtualenv release process, I’ve been working toward fully automating the steps described in the release documentation (https://virtualenv.pypa.io/en/latest/development.html#performing-a-release). Today, cutting a release involves coordinated changes across two repositories, multiple commits, and several file updates. While documented, this remains fairly manual and therefore error-prone. We’ve previously had broken releases due to issues such as a poisoned local cache — precisely the kind of problem that moving the process fully into CI is meant to eliminate. The goal is for version bumps, tagging, artifact building, publishing, and related updates to run entirely in GitHub Actions (see https://github.com/pypa/virtualenv/issues/3048), in a clean and reproducible environment rather than on a maintainer’s local machine.
To enable this, I generated a fine-grained GitHub Personal Access Token (PAT) scoped only to the required repositories. However, GitHub currently requires organization owner approval for fine-grained PATs targeting org repositories, and enforces a maximum validity of 365 days. In practice, this means that even as the virtualenv maintainer, I cannot operate or maintain this automated release flow without owner intervention. In the short term, either approving the pending PAT or granting me admin privileges would immediately unblock the release. But that only addresses the immediate blocker, not the underlying process question.
It’s worth noting that GitHub provides an organization-level setting that can disable required approval for fine-grained PATs and remove mandated maximum validity durations org-wide. The default is to require approval and enforce expiry, but these can be turned off. Legacy (classic) PATs are effectively unrestricted by default anyway. Flipping these settings would likely be the path of least resistance operationally, assuming owners are comfortable with the security trade-offs. That option may be simpler than it sounds and avoids needing to elevate more maintainers to owner status or introduce additional automation infrastructure.
More broadly, the question is what model PyPA wants for cross-repository automation. The options seem to include:
Keeping the current settings and handling approvals/rotation manually.
Granting more maintainers owner/admin privileges.
Switching to GitHub Apps or bot-based credentials.
Adjusting the org-wide fine-grained PAT settings to remove approval and/or expiry requirements.
Defining a clearer lightweight approval policy for maintainers needing scoped automation access.
I’m raising this not just to unblock the current virtualenv release, but to clarify what sustainable path we want going forward. My goal is safer, reproducible releases with minimal manual intervention, while keeping security boundaries appropriate. I’m very open to whichever approach the org is most comfortable with — I mainly want to ensure we pick a solution that doesn’t introduce recurring annual friction or concentrate operational bottlenecks unnecessarily.
To expand on option D: simply remove the need for fine-grained tokens to be approved by an organisation admin and mandated max validity duration for them.
We can tweak these org-wide settings with a few clicks:
(before you get concerned, these are screenshots from a different GH organisation I help to administrate, not PyPA)
Also, even though it may look like fine-grained tokens be granted whatever rights, including write permissions to any repository in the organisation, PATs (fine-grained or legacy) are ultimately gated by whatever individual permissions the creating user has:
A token has the same capabilities to access resources and perform actions on those resources that the owner of the token has, and is further limited by any scopes or permissions granted to the token. A token cannot grant additional access capabilities to a user. For example, a personal access token can be configured with an admin:org scope, but if the owner of the token is not an organization owner, the token will not give administrative access to the organization.
So, since legacy PATs are already wholly unrestricted and grant access to PyPA resources[1], I’m +1 to simply removing the mandated approval and expiry for fine-grained PATs. This is the path of least resistance to unblocking fine-grained PATs which IMO really should be preferred over legacy PATs (to reduce the blast radius if a token is leaked[2]).
I haven’t looked too deep into what’s available (I’m not an org admin anywhere), but if there’s a suitable OIDC/WIF solution for granting specific workflows/environments access to things they need, that would be a better option than a PAT. (The core problem with PATs being that when they leak, they can be used from anywhere, whereas OIDC is inherently restricted to being used from the intended context.)
Is another option to rearrange things so everything can be done inside a single repo?
The release process says you need to do things in pypa/virtualenv and then update pypa/get-virtualenv. Most of the release work is in pypa/virtualenv, whereas a pypa/get-virtualenv release looks like it involves bumping the version in public/version.txt and replacing public/virtualenv.pyz.
Perhaps it’s possible to host and bump public/version.txt and public/virtualenv.pyz in pypa/virtualenv instead, and have pypa/get-virtualenv redirect/point to those?
Not possible. get-virtualenv must happen outside. Let’s not rework the whole system just because we can’t come to understanding how to fix some organizational issues… that being said, even if we do that we still need the PAT to trigger the GitHub release and create a commit within virutlaenv itslef.
I may have misunderstood “we still need the PAT to trigger the GitHub release and create a commit within virtualenv itself.” I thought that part was narrowly about updating virtualenv, not get-virtualenv.
I think we might need some official channel in general about managing the PYPA organization. I requested installation of the Read The Docs GitHub application as described in their latest migration guide for the webhooks and that request essentially goes to someone, but I haven’t heard anything back for the last four days or so.
Today this request essentially just goes into someone’s email box but without the ability to track it or to know who to reach out to. For what it is worth GitHub doesn’t really help because also these requests are sent out but there’s no way to track it if you are not the owner of the organization.
This makes it kinda difficult to maintain a project you’re supposed to maintain when, for an extended period of time, you cannot configure anything significant. perhaps we just need to come up with a better organizational structure but I don’t think what we have today is too good for not being blocking.
At least one of the requests you made (the PAT one) showed up in my inbox, but I don’t have time at the moment to do PyPA admin (especially anything with security implications) so I simply left it for one of the other organisation owners to deal with. (To be clear, I do not consider myself a primary PyPA owner, I don’t even know how I got owner status in the first place).
I think we probably need some owners who do have time to commit to handling admin requests like this, but equally I think it’s important to remember that, like most things in packaging, we’re all volunteers with limited time.
At least part of the problem here is the need for things to be authorised at organisation level rather than project level. I’d hope that most (if not all) day to day activities should be handled at a project level. Do we have a clear list of precisely what needs organisation level approval?
As a followup to this point, I have been told that banning users from contributing is an action that can only be taken at an organisation level. Is that correct? If (for example) an individual was being disruptive on the pip tracker, and we wanted to ban them, how could we do that? Would it require banning the user from all PyPA projects - even ones that might not want to ban the user (for whatever reason)?
I guess the core problem that we might be having here is that: who owns and manages the organisation? Is it the PSF? Is it delegated to someone? It is not really clear today who even should be the point of contact for any change impacting the organisation as a whole. Do we need to reach out to the PSF board, or is it the Python Steering council?
I totally understand that this is a volunteer-driven project and I respect and appreciate people willing to do the work. However I feel like we need some clearer guidance on the path ahead because I feel like now it’s kinda no one’s problem. Which is why no one really feels that they are the one that should be making decisions on changes being requested. Thanks for everyone’s time and effort on pushing ahead this.
I think the core of the problem here still remains: who owns the organisation and is authorized to make these changes? Project maintainers generally have been given access to their project in particular, but there are quite a few settings that require organization-level ownership. I have not gone through one by one and tried to create an exhaustive list of what these are but I ran into them twice within the last month just by trying to improve the release pipeline for my project, so I assume there must be a lot more. Nevertheless even if I would have the list, that would still not give me the answer of who I go to next and using what communication channels.
For what it is worth I feel like in the long term this decision should be with the Packaging Council. however until that becomes a thing, it’s unclear who owns today the rights and has the ability to make decisions.
On one end I feel like historically the PSF infrastructure members did some of this but also at the same time the packaging council proposal would draw its strength from the Python steering council. I’m not sure here. Even if we consider the PSF to own it, I do not think we really have a good point of contact. Who has the final say today?
Historically, sometime was EE, but he did step down. I don’t think he delegated this unofficial responsibility of his to anyone else, as far as I know.
I wonder if it’s worth looking at the question from the other side - what does the pypa GitHub organisation give us here? Do we even need it? This isn’t to say we should drop the idea that these are all PyPA projects, or the PyPA governance rules - I’m talking purely about the github organisation itself.
I’m one of the owners on GitHub, looking at the list of owners it appears to basically be made up of:
Pip maintainers who were active at a particular point of time.
PyPI maintainers who were active at a particular point of time.
A setuptools maintainer (if I recall they explicitly asked to be made owner at some point).
Some PSF staff.
I don’t recall if that information is public, so I don’t want to just post a list of people’s names here in case they don’t want it posted . If you go to this page Members · People · pypa · GitHub are you able to select a drop down that says Owners? It’s hard for me to know what I can see because I’m an owner and what anyone in the org can see.
That makes sense, since originally PyPA was just pip/virtualenv which were being maintained by the same people, and it wasn’t until later that other projects started to be get folded into under the PyPA umbrella. I also suspect people just didn’t think about it so nobody really thought to keep the list up to date in any meaningful way.. and IIRC the PSF stuff got added to help maintain the org, and I believe the PyPI stuff happened because when I was active in all 3 of pip/virtualenv/pypi it made sense to just roll it in as the sort of “second”-ish project.
PyPI has since moved out of the PyPA org for various reasons (mostly technical), and I think it would be fine for others to do that too?
Either way though, as long as the PyPA org is a shared home, we probably need some sort of mechanism for controlling it.
FYI, no, I can’t see owners listed there. Only members, and since you’re listed there without any distinguishing mark, I assume none of the other owners are marked either.
. If you go to this page