Warn maintainers that deleting a project allows the name to be reclaimed

[ncoghlan]

What's the problem this feature will solve?
Maintainers deleting their project may not realise that doing so frees up the name completely, allowing it to be claimed by malware authors, without any managed transfer of maintenance responsibility.

Describe the solution you'd like

• an explicit warning that full deletion allows immediate name takeover
• an easy way to yank every released version instead (preferably as one of the options in the warning notice)

Additional context

• Victor Stinner just did this for several of his projects, and may need help reclaiming the names

[pradyunsg]

/cc @vstinner

[vstinner]

Context.

Six months after, I renamed perf to pyperf and performance to pyerformance (old names confused many people including myself, the original author of perf!). I removed perf and performance projects on PyPI to force users to make sure that they change their habit to install pyperf rather than perf. My expectation was that "python3 -m pip install --user perf" will perf.

But less than 2 hours after I deleted the projects, "perf" and "performance" names were taken again, and so "python3 -m pip install --user perf" now installs a different project, rather than getting an error.

I also removed trollius from PyPI to send a strong signal that the project is no longer maintained. I expected that it would be trivial to republish the project on PyPI. Less than 2 hours later, a developer of Zope recreated trollius with version 2.2. He re-published version 2.1 as well, and then published 2.1.post1 and 2.2.post1 versions. We are discussing to transfer the ownership of the GitHub project.

To be honest, I was very surprised that (1) it was possible to reuse a PyPI name of a deleted project (2) names were taken again very quickly! (maybe because I announced the project removals on Twitter to warn my users?)

Discussion about Trollius removal on PyPI and Trollius maintenance: zopefoundation/ZEO#146

[aguinet]

FWIW, I was also suggesting a temporary name blacklisting when a project is deleted (for a given period of time that needs to be discussed), which could be override by the previous owner (and thus ensure proper ownership transition).

[vstinner]

Discussion about Trollius removal on PyPI and Trollius maintenance: zopefoundation/ZEO#146

Update: Trollius got a new maintainer https://github.com/jamadden/trollius

It seems like Trollius is used by many projects: Zope (and so Plone), Gnocchi, neovim, aiodns, irc3, Python binding of FoundationDB, at LinkedIn, etc. See also jamadden/trollius#16 I didn't know that when I removed my project from PyPI.

Maybe another help would be to show the number of projects depending on a module when its owner wants to remove it. I discovered https://libraries.io/pypi/trollius/dependents website.

[ncoghlan]

I'll also note that the new perf and performance projects appear benign (see https://github.com/isidentical/perf/blob/master/perf/perf.py), but it's still disruptive to end users to have an existing name start installing an entirely different project, rather than failing outright.

[vstinner]

I'll also note that the new perf and performance projects appear benign (see https://github.com/isidentical/perf/blob/master/perf/perf.py), but it's still disruptive to end users to have an existing name start installing an entirely different project, rather than failing outright.

FTR pyperf name was already taken on PyPI 6 months ago, but the owner accepted to transfer me the name :-) So "pyperf" project also changed 6 months ago :-D But it was useful for me in this case.

[pradyunsg]

@ncoghlan Apologies for being pedantic but could you confirm that you checked the sdist has the same contents as the git repository?

[ncoghlan]

@pradyunsg No, I didn't check that, and I agree it would be a good idea.

Also cc'ing @ewdurbin

[brettcannon]

@vstinner the idea of listing dependents is covered by #789

[di]

an easy way to yank every released version instead (preferably as one of the options in the warning notice)

This should be covered by #5837.

I've made #6319 to address this issue.

[ewdurbin]

@pradyunsg No, I didn't check that, and I agree it would be a good idea.

Also cc'ing @ewdurbin

Does this require some action from me? Am I being asked to perform the verification?

[ncoghlan]

@ewdurbin Mainly making sure you're aware of the situation when wearing your work hat, but also to say that I haven't done it myself, and am heading off to PyCon AU tomorrow, so I'm not sure when I'd get to it myself.