[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.