Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

Post reply on HN
Print view View original

21–30 of 198 posts

Re: The lack of namespaces on crates.io is a feature

#21

Post by steveklabnik »

cornstalks wrote: post #3

For those not familiar with Rust or the debate around this subject, "namespace" here is not like a C++ namespace (Rust's modules are analogous to C++'s namespaces). "namespace" here is about the crates.io package registry, not the Rust language. Let's say you have a crate (Rust's terminology for a package) named "foo". Inside "foo" you have a few subcrates (named "foo_bar", "foo_baz", "foo_qux"). There are a number o…

> the team that owns crates.io almost never weighs in on the discussion

There's two big things here:

1. "The discussion" has often happened outside of the contexts that the teams are supposed to evaluate; that is, RFCs are the way in which policies are changed, and the vast majority of the discussions here haven't been on RFCs, but on forum threads. Team members cannot be everywhere, and comments outside of the decision making process are kinda inherently non-normative.

2. Team members used to comment more in these threads but they've gone back and forth and around and around for years, and people are frustrated by it, so they've just stopped commenting in these threads. See #1. When it's optional, and it isn't pleasant, it shouldn't be a surprise that people don't participate.

(I am not on the relevant team anymore, to be clear.)

Re: The lack of namespaces on crates.io is a feature

#22

Post by kibwen »

This article is poorly titled; it's about the lack of namespaces on crates.io. Rust does have namespaces. Cargo is capable of supporting registries that use namespaces. Using Rust doesn't even require one to use Cargo, and using Cargo doesn't require one to use crates.io.

(For the record, I do think that namespaces on crates.io would be a marginal improvement, but the benefits are often overstated and it would add organizational costs that the crates.io maintainers can't currently bear. The amount of ire over this topic is disproportionate to its impact.)

Re: The lack of namespaces on crates.io is a feature

#23

Post by steveklabnik »

simon_o wrote: post #18
steveklabnik wrote: post #15

Earlier quoted context omitted.

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.

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

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.

Re: The lack of namespaces on crates.io is a feature

#24

Post by 013a »

If there was a sports-like betting site for future decisions that major open source projects are going to make, I would put a thousand dollars on "Cargo/Crates will implement namespaces."

The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change.

But, this is the nature of open source (and even startups). New projects start under the (oftentimes correct) belief that they can do something better, which experiences linear extrapolation into believing everything you do is better through virtue of being unlike what everyone else is doing. We see the end-state of Maven, NPM, etc; we don't see the war that those projects went through to reach this state. History is elided, forgotten, then repeated.

Re: The lack of namespaces on crates.io is a feature

#25

Post by lucideer »

steveklabnik wrote: post #15
gw wrote: post #4

You really should look to other ecosystems and see what lessons they've learned. In java, packages are normally "namespaced" by the author's reverse domain name, like `org.lwjgl/lwjgl`. Since clojure uses maven as well, the same applies, but clojure tools like leiningen decided to create a shortcut: if the group and artifact name are the same, like `iglu/iglu`, they can be collapsed into one name: `iglu` Well, that j…

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.

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.

Re: The lack of namespaces on crates.io is a feature

#26

Post by papaf »

steveklabnik wrote: post #15
gw wrote: post #4

You really should look to other ecosystems and see what lessons they've learned. In java, packages are normally "namespaced" by the author's reverse domain name, like `org.lwjgl/lwjgl`. Since clojure uses maven as well, the same applies, but clojure tools like leiningen decided to create a shortcut: if the group and artifact name are the same, like `iglu/iglu`, they can be collapsed into one name: `iglu` Well, that j…

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.

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

Re: The lack of namespaces on crates.io is a feature

#27

Post by steveklabnik »

lucideer wrote: post #25
steveklabnik wrote: post #15

Earlier quoted context omitted.

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.

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 packa…

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.

Re: The lack of namespaces on crates.io is a feature

#28

Post by steveklabnik »

papaf wrote: post #26
steveklabnik wrote: post #15

Earlier quoted context omitted.

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.

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

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.

Re: The lack of namespaces on crates.io is a feature

#29

Post by andrewzah »

kzrdude wrote: post #14
andrewzah wrote: post #11

The lack of namespaces in the crates registry (combined with allowing squatting) is easily one of the worse aspects of Rust.

Please elaborate, why?

Well, what's wrong with namespacing, exactly? Github, java, etc, show us that namespaces are perfectly fine. Not perfect, but fine.

The rest of Rust is extremely pleasant to work with; a lot of thought has been put into ergonomics and I love it as a result.

But with crates.io it feels like the opposite. I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short, meaningful name in English is taken at this point. For what gains? Less forks, less fracturing -in theory-?

I feel like a lot of the arguments for no namespaces are strawmans or make big stretches. For example, figuring out which fork of a project to use is really not a problem. And a lack of namespaces does not fix that anyways, because it's not a code problem... Importing two crates with the same name would be fairly rare, and rust easily solves that with `use crate::... as ...`. Etc.

Anyway, this discussion has been trod to death. There's no point having it, as I'll just be told why I'm wrong and why namespaces are just -impossible-.

Re: The lack of namespaces on crates.io is a feature

#30

Post by steveklabnik »

013a wrote: post #24

If there was a sports-like betting site for future decisions that major open source projects are going to make, I would put a thousand dollars on "Cargo/Crates will implement namespaces." The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footn…

> The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change.

Comments like this are why this discussion has devolved over the years. It's "all heat and no light." It does not help convince anyone that you're right, and if you want this to change, I would suggest that you change your approach.

The team has stated that they are open to implementing namespaces, but that the people who advocate for them need to address the concerns. This hasn't been done successfully yet, and is part of what this post is trying to help out with, by cataloging some of the large amounts of previous discussion.

Post reply on HN