Optional pycqa service account on pypi to ease release process

[ssbarnea]

In order to easy the release management and avoid publishing using personal accounts, projects should be able to publish new releases using a service account.

This service account can be shared across the entire organization even without risking cross contamination by using repository-specific tokens (as opposed to ones that can publish any package).

In order to implement this I already created an account "pycqa" on pypa and I am going to configure it for doc8 project. The bot account is linked to [email protected] private mailing list, private being needed to allow password reset, if needed. At this moment I am the only member of this mailing list but I am more than happy to invite others.

Projects wanting to use this account should:

• add pycqa as maintainer on pypa (not owner!), so it can publish new releases
• configure tokens in their CI/CD of choice, tokens generated by someone with access to the account.

Configuration for GitHub Actions

To configure credentials for github actions, you need to access Secrets section from Settings. Secrets can be organization wide (easy by bit risky as a malicious projects could push a release for another one). If all projects are trusted, no worry.

Credentials are not accessible to PR builds, in case you wondered. More details on how to automate release process can be seen at https://github.com/marketplace/actions/pypi-publish

Configuration for Travis

Already covered at https://docs.travis-ci.com/user/deployment/pypi/

[sigmavirus24]

Still, in order to activate it I had to use a personal email alias sorin.sbarnea+pycqa at gmail.com, which is not ideal as it depends on me. I would be glad to hand this to a private mailing list shared among few org admins (alongside password, in case maintenance is needed).

The reason this shouldn't be done is there is no "admin" or group thereof who can maintain this. I'm the closest thing to an admin and I wouldn't do this because I'd likely just use a personal email address and become a bottleneck preventing folks from releasing their software.

Further, this would be far easier if there was shared infrastructure or if more hierarchy and structure here. None of that exists.

It's also not a goal of the organization to appear to be releasing as one unit or anything along those lines. Projects that choose to sign their releases can't do so with this user.

It seems to me the best way to manage this is with project specific tokens on PyPI. Yes those are tied to an individual's account but I don't see a problem in that.

If instead of having to register a user with PyPI, there was a concept of a "service account" (much like GitHub Apps give you the ability to not need a user to use the API) that could be managed by multiple people (like a project) that seems far more reasonable to offer to the community

[ssbarnea]

PyPI his his part, there is nothing particular to implement on their site for service accounts, there is no difference from their point of view. Behind any service account there is at least one person that can manage it. Using a personal account in a CD integration is always bad idea, mainly because it gives the impression that a particular individual made a release. In reality a release could have being made by any user with ability to push a git tag, most of time a human, but not always (there are project that automated even the tagging decision).

@sigmavirus24 I am not saying you should do it, or that any project should adopt a generic project like I described. As you said, is up to each project to decide.