Namespace support in pypi

What you call “polluted” is actually very common for open source
projects. It’s clear that a vendor will aim to use a more consistent
approach, simply because their internal policies typically require

Please also take into account that in Python PyPI package name !=
Python package name, i.e. a PyPI package is well able to install to
a completely different Python package on PYTHONPATH.

Your example with drop-in PyPI packages for a particular Python
package can easily be made to work, because of this.

The only benefit I see from having prefixes reserved to vendors
is to make it easier for users of those PyPI package to quickly
identify the source of the package.

But then again: they can have the same easy of use by simply looking
at the package maintainer field, so it’s only a very minor win.

1 Like

The biggest advantage for me is that a maintainer can be at peace, confident that their package naming scheme on PyPI is guaranteed to be future-proof.

PyObjC, for example, publishes a number of packages under the pyobjc-framework-[name] prefix, each corresponding to a macOS framework called [name].framework. If Apple announces today a new framework called FooKit, there’s nothing stopping me to publish pyobjc-framework-fookit, and put both PyObjC and its users in an awkward position. Yeah, they can publish their FooKit binding under pyobjc-framework-fookit-real, and it’s easy to identify the actual package by reading the maintainers list, but that’s just annoying for everybody.

Granted, nobody actually does this, but it’s nice to be able to not rely solely on good intent. I feel there are not really any downsides in this proposal, and those minor wins accumulate to make it worthwhile in the end.

One thing that seems to get missed that is a major need for namespaces is to allow entities to be able to run internal package repositories. Without some method for the companies to set up a company namespace there is no way to prevent conflicts between company internal packages and those on the public python repositories.

Simple Example, say there is a large company called largeco that has internal packages under the largeco package namespace.

So they create a package like largeco.coolutils and they have a ton of internal packages that use that package as a dependency.

Then at some point someone creates a totally different package called largeco.coolutils and publishes it to the public repositories.

This breaks all of largeco’s internal packages that use the largeco namespace. Of course if the public package is malicious it could do other things. Many of which could be serious security related issues.

So namespaces aren’t only about knowing the package source but also about being able to prevent package conflicts.


This would also provide a solution to people raising issues like pypa/pip#3454 and pypa/pipenv#2159, where the fundamental problem is pip does not have a way to prefer a package source.

The problem IMO, however, is how to work out a balanced policy. The general criteria mentioned above (can manually apply if the entity has a significant number of packages) is likely not useful to companies wanting to reserve name for internal packages, but a liberal approach (e.g. allow reservation of <name>-* if the entity owns <name> package and/or username) would be very vulnarable to name-squatting. Maybe some compromise would be possible? Say, automatically reserve <name>-internal-* for the owners of package <name>.

I’ve propose something similar ~1 years ago on pypa/warehouse, for more informations see my discussion and ideas here (a sort of idea draft)

So it sounds like we’ve identified three potential use cases for namespaces so far:

  1. Expanding the space of available package names to reduce conflicts and make it possible to publish forked packages without renaming everything.

    • Comment: IMO this doesn’t seem very promising right now, because we don’t have good ways to manage the resulting conflicts at the Python import level. Maybe it’s worth revisiting after we have a robust resolver and Conflicts metadata?
  2. Accurately signaling the origin of public packages. For example, if a package is called largeco-blah, end users might appreciate knowing whether the package is maintained by LargeCo Inc. or not.

    • Comment: this is essentially the same issue that classic trademark is trying to address – giving people accurate information about what they’re getting. We already have some relevant policies here – in particular, PEP 541 has mechanisms for handling trademark disputes – but they’re fairly ad hoc; this would be systematizing them. Some challenges include: how do we handle the tension between names that designate origin vs names that describe usage (e.g. pygithub is a package for working with github, so it’s an accurate descriptive usage, but it’s not maintained by GitHub Inc.)? How do we effectively communicate the difference to users? If PyPI is going to be in the business of promising to users that azure-storage comes from Microsoft, then how do the PyPI administrators figure out that they’re actually talking to Microsoft and not some scammer? (This is basically the same problem as Certificate Authorities have to solve, and it’s highly non-trivial.)
  3. Reserving portions of the namespace for private usage. Lots of organizations have internal packages; they definitely don’t want to accidentally get a public package that happens to use the same name, and they would prefer that no such public package exist (since it’s awkward to have unrelated packages where you can’t install both of them at the same time, and maybe their package will become public later).

    • Comment: This is essentially asking for PyPI to create a formal, blessed way to squat names. So the challenge would be to find a way to balance the public’s desire to keep names available to use and not be locked up by speculation or some opaque and unaccountable process, versus organizations’ desire to avoid accidental conflicts. One approach might be to carve out a specific namespace for this usage, e.g. prohibit packages on PyPI that start with private- and then document that everyone’s internal packages should use this. In the mean time, there are other options like using devpi (as noted up thread). This is clearly a common problem though, so at a minimum we should have some docs addressing it.

Thanks for the summary, @njs!

For those who haven’t been following it, here’s the GitHub issue about planning the rollout of the new pip resolver.

I believe @dustin is working on the PEP 541 process (and, towards that goal, on a user support ticket for PyPI.) Perhaps he could speak more to how frequently we see trademark questions come up currently among those support requests?

Perhaps this could be on – anyone want to take a stab at writing this up as a guide and improve along the way? People do want clearer and more discoverable recommendations for the intersection of private stuff and PyPI.

The typeshed project, which provides PEP 484 type stubs, is currently discussing to distribute non-standard-lib type stubs via pypi ( Currently all stubs are vendored by the type checkers, but this approach doesn’t scale. Similar to DefinitelyTyped in the JavaScript world, we’d like users of a package foo to be able to install the corresponding stubs by just typing pip install or something similar.

But we’d need to ensure that people can’t squat these names for security reasons. As opposed to other Python packages, people will just try to install the type stubs without previously checking them, and they should be able to. But without namespacing this would open a wide door to attackers. So for us, namespacing is essential.

From the descriptions above, I’d agree with that. It sounds like the problem statement they started with was very similar to ours, and so the solution ended up offering characteristics we consider desirable: genuinely opt-in (so the folks for whom the existing flat namespace is working well don’t need to care), and with a centrally administered approval process so you didn’t get a proliferation of vanity namespaces producing install time package conflicts.

Slightly related since it’s relevant for internal-only packages, will never have a classifier that starts with "Private :: " and it rejects uploads with invalid classifiers. (PR w/ link to a tweet)


Has there been any progress on Nuget-style namespaces? If not, is the blocker development time or a PEP?

As far as I am aware there has been no progress. It would require someone to write and champion a PEP, and then someone to implement it assuming it got accepted.

Addding a belated note on the “private package” problem: Linux distros face a variant of this with system API binding packages that are installed directly into the system Python by a primarily C/C++ focused build process instead of being published as regular Python packages.

I think any PEP should put this into the “No need to solve” category though, for the following reasons:

  1. These are open source projects, so they (or a consuming distro) are free to make an sdist and publish it to PyPI (best resolution)
  2. Distros that allow for multiple Python stacks or fully support venvs will likely want the sdist anyway, so the bindings can be used outside the system Python (encourages the best resolution)
  3. When there are technical barriers to the best resolution, actual namesquatting is a defensible interim measure given the availability of PEP 541 to address disputes (e.g. I’ve held the “rpm”, “dnf” and “solv” names on PyPI for years, and relatively recently allowed a team from Red Hat access to the last to publish real libsolv bindings).
    4.The namesquatting workaround could be made more systematic (similar to the blocking of stdlib names), but any prefix based name reservation would only apply to future explicitly distro-controlled packages and, for that purpose, distros fall under the same design category as “largeco” in NJS’s write-up.

See proposal for name reservations: PyPI as a Project repository vs. Name registry (a.k.a. PyPI namesquatting, e.g. for Fedora packages)

I don’t think distros need prefix name reservation. Who’d be the gatekeeper? If someone random contributor wants to write a Fedora-specific tool and name it fedora-foobar, they should go right ahead. (Though of course, just foobar would be a better name—if it’s good, others might want to adopt it.)

#988 is now closed as pip 20.3 has the new resolver on by default.

Hi all, in light of Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies | by Alex Birsan | Feb, 2021 | Medium is now an appropriate time to revisit this & Improving risks and consequences against typosquatting on pypi - #12 by PoluX ?


IMO this is not (directly) related to the issue. As you can read from the article, npm (which does support namespacing) is still affected by the issue. On the flip side, the issue can be quite easily prevented by registering placeholder packages on PyPI even without namespacing, and I believe the PyPI team accept requests to reserve names without actually publishing any releases as well. Namespacing can make prevention a bit easier, but can’t help much, nor is necessary to avoid it from happening.

Agreed. Although it may make it easier to make a clear distinction between what is <company A’s> and what isn’t.

and I believe the PyPI team accept requests to reserve names without actually publishing any releases as well

Is there a sanctioned/“official” means of doing this?

This is true only when package publishers fail to make use of the namespace support. If PayPal’s auth-paypal package had been named @paypal/auth, with PayPal in control of the @paypal scope, they would not have been attackable using this technique.

Solving this problem requires both namespace support, and awareness of that support’s existence and its importance.


You can squat a package name without namespacing as well (at least on PyPI); if auth-paypal were a Python package, they could claim that name on PyPI with a stub package, or ask for PyPI admins to give it to them. Namespacing makes the process much easier, but it is not required.

p.s. To be clear, I’m fully supportive of having namespace support in Python packaging. But it should not be presented as a requirement incorrectly.