Reserver is gone, but PyPI's name reservation problem isn't

A package name can look free and still be hidden conflicts. You usually don’t find out until you try to publish.

Python

Python Programming

Software Development

Open Source

Reserver is gone, but PyPI’s name reservation problem isn’t!

OpenSciLab

7 min read·

Sep 29, 2026

--

TL;DR: PyPI has no reliable way to check if a package name is available, so we built Reserver to help developers secure names early, transparently. PyPI made us remove it without fixing the underlying problem, and we think the community deserves a better solution.

Imagine you are a software developer planning your next project. You come up with your favorite name and want to make sure it is available on the package manager, PyPI in the case of Python, so you can have a consistent name for your repository and your package. But how can you actually check if the name is available? Currently, there is no trustworthy way.

You may first search for the name on the PyPI website. There is no package with that name, so you should be able to use it, right? Not necessarily. If the name you are trying to reserve is considered too similar to another existing package, PyPI may reject it. There are also banned or reserved names that you cannot use, but you may not know that your name is one of them until you actually try to reserve it. In some cases, even if there is no package with that name, an existing package with the same repository name may also prevent you from reserving it.

The community has been aware of these naming conflicts for years, as reflected in PyPI issues like (#11408, archive), where developers frequently run into unexpected name availability and collisions. The worst part is that you may only discover this after you have already developed the first version of your project. At that point, you have created your repository and used the name throughout your project, and may already advertise for it. Only then do you find out that the name is not available, and you have to go back and change everything.

You built the package, named it, and announced it. Then you out you can not have the name.

We built Reserver for package developers to check for available names and secure a project name during early development. The community adopted Reserver, with at least 100 projects using it, including xAI’s grok-cli-bin. This shows not only that Reserver filled a gap in the developer experience, but also that the community used it in good faith. This need is becoming even more relevant in the era of AI-assisted software development, where the time it takes to turn an idea into software has become a fraction of what it used to be.

From the early days, we were aware of the potential misuse of such a tool for name squatting. To ensure full transparency, we added a visible watermark to any project taken with Reserver: “This name has been reserved using Reserver.” This allowed both us and PyPI administrators to easily track its usage and identify potential name-squatting attempts. We also included a clear disclaimer against such misuse, showing our good faith and best effort to prevent it.

Reserver was quarantined.

Ironically, the transparency we built into Reserver made it easy for PyPI to notice its use. The visible watermark on every reserved package clearly identified packages created through Reserver, and PyPI’s security team reached out to us about it, raising concerns that Reserver “promotes name squatting and spam,” and that abandoned or improperly reserved projects “could create additional administrative overhead for the PyPI team.” They ultimately quarantined the Reserver package on PyPI.

Reserver was specifically designed for developers with genuine projects under active development, not for holding names indefinitely or registering large numbers of names. More importantly, Reserver does not give developers any capability they do not already have. It is a client-side abstraction over the existing PyPI publishing workflow. Every package is uploaded through the developer’s own PyPI account and API token, using the same underlying process that could be done directly through Twine or a simple custom script.

In other words, Reserver does not create the name-squatting problem. It democratizes a process that was already possible with some pieces of code. Removing Reserver does not remove that capability. A developer can perform the exact same operation without the tool, just without the transparency and traceability provided by Reserver’s watermark. This was also happening before Reserver. Vercel.ai, for example, secured the chat and ai package names, which had previously been owned by a Chinese name-squatting account (archived chat and archived ai). Reserver did not introduce the ability to secure a package name early. It made that existing process accessible and visible.

We explained this distinction to PyPI and made it clear that we were willing to work with them. We offered to change Reserver’s documentation, warnings, confirmation process, default behavior, or other aspects of the tool to better align with their expectations. We also asked what safeguards they would recommend and which specific part of PyPI’s Acceptable Use Policy the tool itself violated, as opposed to violations that could be committed by individual users.

A few months later, PyPI got back to us with their final decision. They rejected our arguments. Their position was that placeholder packages are invalid from the moment they are uploaded, regardless of whether they represent genuine projects under active development or later become functional packages.

They also made clear that no safeguard we could add to Reserver would resolve their concern. Instead, their answer to the underlying problem was that developers should only claim a name once they have working software ready to publish. We were given 14 days to remove Reserver from PyPI ourselves; otherwise, PyPI would remove it, adding that they preferred us to do so ourselves in order to “keep your account and your other projects in good standing.”

We believe the underlying problem should be addressed at the platform level. PyPI, similar to other package managers like npm, could provide an API that allows developers to reliably check whether a package name is actually available before investing in that name. This would give developers a trustworthy answer early in the development process and not make them discover naming conflicts when they are ready to publish.

At the same time, name squatting should be addressed at the user level. Since every upload is tied to a PyPI account and token, PyPI can easily identify and restrict users who abuse the system to reserve large numbers of names. Instead of blocking a tool that makes an existing capability more accessible, controls at the account and token level could target the ill-intent users actually engaging in name squatting.

Let developers check names upfront, and stop the accounts that squat.

What’s Next?

After waiting months for a response, we were disappointed not only by PyPI’s decision, but also by the tone of their final message. Rather than continuing the discussion around possible solutions, we were given 14 days to remove Reserver ourselves.

We removed Reserver from PyPI to protect our accounts and our other packages, but we refuse to stay silent about this approach to governance. We urge the Python community to ask themselves: is this the ideal way we want our package manager to treat developers who raise a real problem and try to build a solution for it?

Removing Reserver does not solve any of the issues that motivated us to build it. Developers still have no reliable way to check whether a name is actually available before their project is ready to publish, and bad actors can still use the existing publishing workflow. This approach simply puts it in the attic, out of sight.

Removing Reserver hides the problem. It doesn’t solve it.

Who Are We?

We are OpenSciLab, an independent, non-profit team of open-source developers building scientific and developer tools. Reserver is not our first Python package, and PyPI is not a platform we approached without experience. Over the years, we have built and maintained projects including

We have spent years contributing open-source software to the Python community. We are sharing this story as developers of the Python community, who build for it, maintain packages in it, and care about how it is governed. First it’s Reserver. If you say nothing now, then when they come for yours, there will be no one left to speak for it.