4 ms·

> Crates.io and Cargo need namespaces, but the leadership flatly says no. They are favorable to crate-name-as-namespace (so that once you have the tokio crate

by stymaar 4mo ago

> Crates.io and Cargo need namespaces, but the leadership flatly says no. They are favorable to crate-name-as-namespace (so that once you have the tokio crate you can use tokio as a namespace) and there's ongoing work on that. But as said above, it takes work to implement. There's no desire for other meaning of the word "namespace" because famously nobody ever made a well-reasoned proposal (despite the amount of social media outrage over the lack of namespace).

kelnos 4mo ago
There's just so much prior art here, though. Docker hub has username-based and org-based namespaces (as well as a "blessed package" root with no namespace). Maven central uses reverse-DNS as a namespace (and Maven central/OSSRH requires that you prove you own the domain before you can publish to it). Even npm, probably the poster child for doing things wrong, has user- and org-based namespaces. This isn't a particularly difficult problem, and other package ecosystems have solved it many times in the past.
- stymaar 4mo ago
  Arbitrary user-based or org-based namespace have many drawbacks: to name a few it makes discoverability much worse, and as such makes it easier to sneak in a malicious dependency, and it requires much more work on the package manager side to make sure that orgs are actually related to the company they use the name from (i.e. how do you make sure that the org "Google" in your package manager does indeed belong to GOOG), and a litigation process to resolve conflict (what if someone had created an Anthropic user name back in 2016?). And on the flip side nobody has ever been able to articulate (that is, not in a hand-wavy fashion) what do those actually bring on the table to make those extra costs worth it.
  - echelon 4mo ago
    > much more work on the package manager side to make sure that orgs are actually related to the company In a world without namespaces, how does anyone know google-foo belongs to Google? At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs. > (what if someone had created an Anthropic user name back in 2016?) https://github.com/anthropic https://github.com/anthropic https://github.com/anthropics https://github.com/anthropics Lol. The world seems to be moving along just fine. I don't think the problems you list are problems at all. Meanwhile, the benefits of knowing everything under a user/org namespace belongs to a user/org are huge. There are much bigger problems to worry about than this. Such as if a popular crate owner sells out to malware for $$$. It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. The org can uniformly control permissions to all member crates without having one go rogue.
    - stymaar 4mo ago
      > In a world without namespaces, how does anyone know google-foo belongs to Google? It doesnt. And nobody believes it does. That's the key difference. > At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs. In practice nobody “establishes” that, they just trust the platform for vetting the orgs (and they are right, because they usually do), so if you package manager uses the same formalism without the same guarantees, you're setting yourself for a bad time. > Lol. The world seems to be moving along just fine. You've just shown an example that it doesn't! If you have two packages "anthropic/claude-code" and "anthropics/claude-code" how is the user supposed to know that the scammy-looking second option is the legitimate one? > There are much bigger problems to worry about than this. The thing is that mandatory namespaces don't provide meaningful benefit at all. > It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. This is covered by the accepted “crate as namespace” proposal. It has the benefit of keeping a flat namespace by default and providing an optional namespace for open source projects like that.

by stymaar 4mo ago

kelnos 4mo ago

There's just so much prior art here, though. Docker hub has username-based and org-based namespaces (as well as a "blessed package" root with no namespace). Maven central uses reverse-DNS as a namespace (and Maven central/OSSRH requires that you prove you own the domain before you can publish to it). Even npm, probably the poster child for doing things wrong, has user- and org-based namespaces. This isn't a particularly difficult problem, and other package ecosystems have solved it many times in the past.

stymaar 4mo ago
Arbitrary user-based or org-based namespace have many drawbacks: to name a few it makes discoverability much worse, and as such makes it easier to sneak in a malicious dependency, and it requires much more work on the package manager side to make sure that orgs are actually related to the company they use the name from (i.e. how do you make sure that the org "Google" in your package manager does indeed belong to GOOG), and a litigation process to resolve conflict (what if someone had created an Anthropic user name back in 2016?). And on the flip side nobody has ever been able to articulate (that is, not in a hand-wavy fashion) what do those actually bring on the table to make those extra costs worth it.
- echelon 4mo ago
  > much more work on the package manager side to make sure that orgs are actually related to the company In a world without namespaces, how does anyone know google-foo belongs to Google? At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs. > (what if someone had created an Anthropic user name back in 2016?) https://github.com/anthropic https://github.com/anthropic https://github.com/anthropics https://github.com/anthropics Lol. The world seems to be moving along just fine. I don't think the problems you list are problems at all. Meanwhile, the benefits of knowing everything under a user/org namespace belongs to a user/org are huge. There are much bigger problems to worry about than this. Such as if a popular crate owner sells out to malware for $$$. It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. The org can uniformly control permissions to all member crates without having one go rogue.
  - stymaar 4mo ago
    > In a world without namespaces, how does anyone know google-foo belongs to Google? It doesnt. And nobody believes it does. That's the key difference. > At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs. In practice nobody “establishes” that, they just trust the platform for vetting the orgs (and they are right, because they usually do), so if you package manager uses the same formalism without the same guarantees, you're setting yourself for a bad time. > Lol. The world seems to be moving along just fine. You've just shown an example that it doesn't! If you have two packages "anthropic/claude-code" and "anthropics/claude-code" how is the user supposed to know that the scammy-looking second option is the legitimate one? > There are much bigger problems to worry about than this. The thing is that mandatory namespaces don't provide meaningful benefit at all. > It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. This is covered by the accepted “crate as namespace” proposal. It has the benefit of keeping a flat namespace by default and providing an optional namespace for open source projects like that.