[NoboruWataya]

Namespace pollution is an annoying problem in Rust. A while ago I was looking for a crate to help build something to interact with Apache Solr. Great, there's a Rust crate called `solr` on crates.io. And here it is: https://github.com/lambdastackio/solr-rust

There are other examples of crates registered on crates.io with prominent names that are just stubs with one commit from years ago. I'm sure this problem also exists for other languages but it feels worse with Rust, I suspect because of how easy it is to register a crate on crates.io combined with the "rewrite X in Rust" craze.

[andriy_koval]

If you sort by recent downloads, you find that https://crates.io/crates/solrstice looks likely most popular

[insanitybit]

How do namespaces help? I'm building a package registry and I've decided against namespacing because I can not see how to implement it in a way that doesn't just lead to even worse problems.

[vlovich123]

Because @apache/solr would be easier to disambiguate vs @randomuser/solr.

You should really build namespaces in from the start, or at least reserve the capability to do so in the future. Unless you want to speed run all the lessons already learned.

https://nesbitt.io/2026/02/14/package-management-namespaces....

[insanitybit]

What stops someone from just squatting the namespace? What is the concrete value? Who gets a namespace? Who gets "apache"'s namespace? Is it a problem if a user takes "apache" or "anthropic"? Do you use domain registration to determine who owns a namespace?

I'll read the article soon fwiw, but those questions come to mind. I'm definitely open to it.

For now I have:

1. Minimum "typo distance" between package names, unless within the same author.

2. Trusted Publishing + 2FA to promote from "published" to "released" required, no API keys.

3. 1 day dependency cooldown by default.

4. The language (and the build system, built in the language) has explicit capabilities model so you can statically verify what build scripts are allowed to do.

I feel like the benefit of namespacing must be quite low at this point but perhaps I need to reevaluate.

[vlovich123]

If you can’t be bothered to read the paper that covers all of it, why should I be bothered to respond? Do whatever you want, I’m just highlighting this space is well studied and you’re insisting on retreading ground where the consequences are well-studied.

[insanitybit]

As I said, I will read it (in fact, right now!). Perfectly reasonable to say "that's all addressed in the post", of course.

edit: I'll have to reread it perhaps. I feel like the article largely motivates my points about how complex namespace registration is and how it just punts the problem (or adds new problems like "you hijacked the entire namespace"). It doesn't seem like there's a strong proposal in the article other than to make namespaces support built-in by default to make later migrations easier if a solution does come about, which is reasonable and something I can do.

I'll read the linked PEP/RFCs to learn more about how others are solving this but I think my opinion is still mostly that registries trade some problems for other (worse?) problems.

At minimum it seems notable to restrict package names in general as it allows more options for denotation in the future.

[vlovich123]

Right. I think the strongest is to tie the namespace into the language’s module system if possible like what cargo is trying to do. It depends on the language. DNS namespaces also work provided you add a key to guarantee a DNS takeover doesn’t take over the package namespace.

But the important point is to reserve support to add namespacing in the future even if you punt on it initially. Although I still argue as a security measure it’s better to support namespacing from the get go. Trust and authorship are valuable. There’s also all sorts of cryptographically strong ways to guarantee namespace owenrship that haven’t been explored (eg how tor can do vanity domain name creation)