[steveklabnik]

We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm. Both the good and the bad.

And also by the experience of going through GitHub hosting a RubyGems server and all the fallout that happened there.

[lucideer]

I have less experience with CPAN and RubyGems but npm's namespacing system has two very serious problems:

1. It was introduced very late, meaning the community had already formed patterns of contribution around a flawed flat system. This is a problem of the flat system, not of the namespaced one.

2. It is still to this day entirely optional (for understandable backward compat. reasons). This gives namespaceless packages a misplaced position of authority over namespaced ones, which erodes the value of namespacing.

These are tough problems to get around if you start with a flat structure, but they really just outline the urgency of switching to namespaces for a relatively young project.

[steveklabnik]

I agree with a lot of this perspective. It's also directly relevant to our situation, because we are basically in exactly that place now, and dealing with these problems is something that proponents of adding namespaces need to navigate.

[didibus]

This is the only good argument I've heard yet for not adding namespace. And maybe it's a defeating argument, maybe Crates is doomed to not have namespace due to the cost of putting them in after the fact.

[lucideer]

I'm not sure you followed the above 2 points, or perhaps read them through tinted glasses.

I wasn't arguing that npm's namespacing system is worse than their initial system, nor that their switch to namespacing was a mistake.

The current npm namespaced system, with flaws, is head-and-shoulders better than the previous flat system.

You're saying you did "look and learn". If by that you mean you looked at the end product (npm's is seriously flawed) without looking at the journey to that product (npm's is still a huge improvement over what they started with), then you're not going to learn much from that kind of "looking".

I highlighted Composer/Packagist in a sibling comment as a system you should look and learn from (w.r.t. namespaces).

Choosing to only look at flawed systems that started flat seems like you're just being selective to support your own thesis.

[lucideer]

PHP and it's ecosystem has a lot of problems, but I think Composer/Packagist is as surprisingly exemplary example of how to go about structuring package management.

[lotyrin]

Except for the decision to not tackle solutions for native extensions.

[hansjorg]

Add a "legacy" namespace and move all existing packages there. Allow for a transition period where tooling will add "legacy" to instances where no namespace is given. Add a mechanism for legacy packages to indicate their new namespace so that transitioning could be mostly automatic for package users.

Not effortless, but not necessarily very costly either.

[papaf]

We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm.

Don't those package registries all suffer from not having namespaces? RubyGems in particular [1].

[1] https://thehackernews.com/2020/04/rubygem-typosquatting-malw...

[rat87]

Namespaced packages have almost the same problem

People can just have maliciously typeo-d namespaces

Actually you could argue it's worse since people tend to pay more attention to package names rather then namespace names

[steveklabnik]

Everything has upsides and downsides. There are downsides to the Rubygems approach.

However, typosquatting is an orthogonal problem to namespacing, you can still typosquat a namespace.

[papaf]

From the article:

This is not the first time typosquatting attacks of this kind have been uncovered.

Popular repository platforms such as Python Package Index (PyPi) and GitHub-owned Node.js package manager npm have emerged as effective attack vectors to distribute malware.

"Orthogonal" suggests no connection but what I see above is a list of package managers that don't have namespacing.

[steveklabnik]

They didn't make the claim that no namespaces had anything to do with this, that's an inference you're making from the specific list, when it could be for any number of reasons. For example, these are some of the largest package management ecosystems in the world, so they're more likely to be attacked than smaller ones. (You can of course come back and say that there are other massive ecosystems too, but that's kind of my point: there's more to a discussion than a random article listing a few ecosystems.)

I stated my reasoning in my comment: you can typo squat a namespace, just as easily you can any identifier. I don't see any inherent difference between the two.

[arthur_pryor]

> "Orthogonal" suggests no connection but what I see above is a list of package managers that don't have namespacing.

correlation does not equal causation.

how is it not apparent that typosquatting is possible regardless of whether namespacing is in play?

for example, URLs are namespaced, and are the classic example of typosquatting: https://en.wikipedia.org/wiki/Typosquatting

[simon_o]

I think what the GP wanted to say was along the lines of "look at _better_ approaches", not just "look at approaches".

[steveklabnik]

Maybe. Regardless of what my parent meant, a lot of people in these discussions imply that we never looked at prior art because we did not make the choices around the tradeoff that they wanted us to make. And we did look at many, many approaches. We just decided to not go in those directions.

[gw]

I wasn't even addressing the crates.io team, i was addressing the author of the post.