You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PyPI supports pending publishers for pre-registering a trusted publisher for a nonexistent PyPI project. This breaks the "chicken and egg" cycle of having to create a project before registering a trusted publisher to it.
To support this, PyPI allows multiple pending publishers to be registers to a future PyPI project name, with "first come first serve" rules -- the first workflow to actually use the pending publisher is the one that creates the project + has the full TP assigned to it.
To make this work, PyPI has uniqueness constraints on pending publishers that are similar to normal TPs. For example, for GitHub, a pending publisher must be unique on (owner, repo, workflow, environment?) -- only one pending publisher for that tuple may be created, and attempting to create multiple fails.
That works well for most users, but it results in an edge cases for monorepos (i.e. one repo, multiple Python projects). To bootstrap a monorepo a user might want to create N pending publishers, one for each project. However, they can't currently do this send pending publishers currently have unique repo identities.
Monorepo users have a few workarounds available to them:
They can go back to the "chicken and egg" approach and create the project(s) via an explicitly provisioned API token, and then register normal TPs as usual;
They can create a single pending publisher for one project within the repo, perform a publish event, and then manually enroll the other projects with the now-created TP;
They can do everything with manually provisioned API tokens and skip TP entirely (which we don't want to encourage)
All three of these are suboptimal from a UX perspective, and all three are semi-undocumented (in the sense that the monorepo case isn't explicitly called out as an edge case in the TP docs).
Action items:
Can we improve the UX here? Conceptually the monorepo case requires loosening the unique constraint, which is unsound/impossible (since we need to uniquely map back to the TP during pending -> normal conversion). But there might be a way to do this that doesn't cause uniqueness issues there; requires more thought.
We should explicitly call out the monorepo pending publisher case in the docs.
PyPI supports pending publishers for pre-registering a trusted publisher for a nonexistent PyPI project. This breaks the "chicken and egg" cycle of having to create a project before registering a trusted publisher to it.
To support this, PyPI allows multiple pending publishers to be registers to a future PyPI project name, with "first come first serve" rules -- the first workflow to actually use the pending publisher is the one that creates the project + has the full TP assigned to it.
To make this work, PyPI has uniqueness constraints on pending publishers that are similar to normal TPs. For example, for GitHub, a pending publisher must be unique on
(owner, repo, workflow, environment?)
-- only one pending publisher for that tuple may be created, and attempting to create multiple fails.That works well for most users, but it results in an edge cases for monorepos (i.e. one repo, multiple Python projects). To bootstrap a monorepo a user might want to create
N
pending publishers, one for each project. However, they can't currently do this send pending publishers currently have unique repo identities.Monorepo users have a few workarounds available to them:
All three of these are suboptimal from a UX perspective, and all three are semi-undocumented (in the sense that the monorepo case isn't explicitly called out as an edge case in the TP docs).
Action items:
h/t @miketheman
The text was updated successfully, but these errors were encountered: