Stop Allowing deleting things from PyPI?

Packaging
78

In talking to people outside of this thread, another concern has come up that I’m not entirely sure how to handle it yet, but I want to mention it to say that (1) I am thinking about it, and (2) throw it out there for others to brainstorm too.

The general thrust of the concern is that if an author wanted to distance themselves from a project, or from PyPI itself, they’re currently able to do that on PyPI by deleting the project and then deleting their account on PyPI.

Currently PyPI allows you to delete your account on PyPI only as long as you are not the sole owner (not maintainer, owner) of any projects on PyPI, encouraging you to either hand those projects off to other people or delete them as makes sense.

Obviously with any of the proposals here, authors are going to be able to fall into situations where they cannot delete their account because there is nobody available who wants to take over any projects that are not able to be deleted by any of the above rules, which means they’re forced to remain associated with that project and/or PyPI [1].

Now to some extent this is unavoidable. PyPI is constrained such that it cannot mutate the artifacts on PyPI itself, so any metadata inside of that artifact that links the developer to that project cannot be removed or changed in anyway. Additionally, the metadata the PyPI stores in the database that logically is sourced from inside of the artifact needs [2] to match the data that is inside of the artifact itself, which limits our ability to change that metadata.

However, I do think that there is an underlying issue here outside of the metadata itself, which we should give some thought to, and how we handle them.

Off the top of my head, I see a few possible options:

  1. Do nothing, as there are at least three possible work arounds:
    • Users on PyPI can change their name, email, avatar, everything except for their actual username, allowing them to replace it with some form of anonymization.
    • They could create a new user account with an anonymous username, transfer all of their projects to that, and remove their “real” account from those projects, which would then allow them to delete themselves.
    • From an end user point of view, project level yank is pretty close to deletion since it removes the project from all user facing content, and the simple API is basically just a list of files with some related metadata (hashes, python-requires, etc). That doesn’t let the person get rid of their PyPI account, but if they just want to distance themselves from a project, it’s pretty close.
  2. Add the ability to change your username on PyPI, but otherwise do nothing [3].
  3. Allow users to hide their association with a project in the public UI/API [4].
  4. Enable some way for a user to “abandon” a project, removing it from their account but not deleting it [5][6].

Of those, all 4 options allow a user some level of distancing themselves from a project, but only the (4) option provides a user the ability to completely walk away from PyPI and sever all connection and remove all accounts they have [7].

  1. Interestingly enough, the more restrictive policy actually handles this better, since the “half measure” policy doesn’t allow deleting projects at all you’re forced to hand off even nonsense packages like dstufft.testpkg2 unless they’re brand new. The more restrictive policy only requires you to hand off packages that have more than some number of downloads (1000/mo or whatever number would actually get settled on). ↩︎

  2. For a lot of historical reasons, this isn’t enforced today, nor has it ever been. The direction we’ve been moving though has been to narrow the gaps where this isn’t the case, in the hopes of eliminating them for new things on PyPI, but it’s unlikely that will ever be something we can apply retroactively. ↩︎

  3. This is basically just accepting the first option as the official way of doing this and closing the gap on the last piece of a user account that you can’t change. ↩︎

  4. This would be similar to how GitHub allows users to choose whether or not their membership in an organization is public or not. It would still show up on the management UI for that project, but not in public facing pages. Still obviously doesn’t allow people to step away from PyPI itself but lets them hide their association with a project. ↩︎

  5. This would effectively mean that an abandoned project is forever read only unless we allow some form of PEP 541 take over to pick up maintenance on a project. Implementation wise, we could either just remove all roles from the project or create a PyPI admin-controlled account to act as the holder of abandoned projects. ↩︎

  6. One could even imagine fleshing this feature out more, providing some sort of match making service that allows people to match up with abandoned projects that need maintenance. Of course, there’s still the underlying problem of determining who to trust to hand an abandoned project off to, but that would be a problem for someone actually proposing that hypothetical match making service to solve. ↩︎

  7. Of course, there is still the implicit association inside of the artifacts themselves and/or inside of the metadata that came from those artifacts, but as mentioned earlier that is unavoidable due to technical constraints. ↩︎

4 Likes