5 ms·

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 namespac

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 of situations where a crate will have subcrates. Sometimes these subcrates are intended to be used publicly (e.g., you want people to be able to use just the "foo_bar" subcrate if they don't need the whole "foo" crate) Sometimes these subcrates aren't intended to be used publicly (e.g., Cargo forces you to put your proc macro in a separate crate, but that's an implementation detail of "foo" and isn't something other people should use directly). So now you have "foo" on crates.io, as well as a bunch of "foo_*" subcrates on crates.io. Currently there is nothing stopping some random developer from publishing their own "foo_haha" crate. This new crate isn't related to your "foo" crates and might even be squatting on a name you would have liked to use for a subcrate. Or multiple people might want to create different crates for similar things. e.g., there are multiple regular expression crates. But only one of these crates got the "regex" name. Everyone else has to use a different name, and sometimes people use creative (unintuitive) crate names. So for various reasons, some people want namespacing on crates.io that would allow someone to reserve an entire namespace. This would allow you to prevent others from using a name that might be confusingly similar to yours. It also allows you to use conflicting crate names if multiple people want to publish different crates with the same name. TL;DR some people want something like npm's scopes for crates.io. And other people don't want it. This has led to much debate and arguing and whatnot. It's funny, though, because the team that owns crates.io almost never weighs in on the discussion, and on the rare occasion that one of the team members does say something they always do it in a personal capacity and not in a way that represents the team. This has created its own set of frustrations.

AuthorizedCust 6y ago
The article's title is poor. "namespaces in [language name]" should be about the traditional computer science notion of namespaces. A better title may be "No Namespaces in Rust's Package System Is a Feature", although that is long.
- dang 6y ago
  We edited the title following kibwen's suggestion: https://news.ycombinator.com/item?id=24444812 https://news.ycombinator.com/item?id=24444812
steveklabnik 6y ago
> 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.)
- krainboltgreene 6y ago
  I mean while I absolutely understand the latter situation, the former doesn't feel as understandable because the team could just...make an rfc for it. If you community is clamoring about something, but no one has stepped up to make an RFC for the situation, you have to do two things: 1. Make an RFC for the clamor 2. Figure out why no one has done this already As you know, the lack of response is as much a response as any response.
  - steveklabnik 6y ago
    "Make an RFC" means coming up with a comprehensive plan for implementing the feature. If the team says "hey we're not sure we've ever seen a plan that addresses our problems," then it's not really their job to figure out how to address those problems, it's the people who actually want the feature. That may be the team, of course, if they think that it is important enough to pursue. There are people who actively do not want it too, and you can't forget about them. The way you've written this sorta suggests that everyone but the team wants this thing, but the team is ignoring them, but that is very much not the case. It's just a contentious issue with tons of people on every possible side. There are more than two! Also, characterizing it as "no response" is not accurate, as I said, people have not come up with proposals that addressed concerns. It hasn't been ignored. Just not every person has the ability to comment on every thread in every forum. And there have been some people who have put forward proposals. There's an open RFC I linked downthread about a related problem, "crate name transfer," and there was an RFC that was opened two weeks ago, but the person closed it rather than respond to the team's feedback. That there haven't been successful proposals is different than "there have been no proposals." Personally, I think that we haven't had movement because it is an incredibly complicated space, with a ton of overlapping desires, and a lot of complexity, and a lot of angry, low-signal discourse. That nobody wants to wade through all of it isn't surprising. I'm glad this blog post was created; it's the exact kind of work that needs to be done to get things moving in a positive direction.
wnevets 6y ago
is there a TL;DR for why some people don't want namespaces for crates? Is it just because NPM does and javascript is bad or is there something else I'm missing? I couldn't imagine github or npm working well without them.
- steveklabnik 6y ago
  > Is it just because NPM does and javascript is bad Not at all! In fact, npm's implementation is why some are pro, but also why some say that it's not worth it; see https://news.ycombinator.com/item?id=24444852 https://news.ycombinator.com/item?id=24444852 for some npm specific sentiment. (Incidentally, npm added scoped packages in 2015, after these decisions were made for crates.io. However, crates.io is still smaller than npm was then...) There isn't really a TL;DR because this space is complex, and there's a lot of details, and they matter, and different people have different reasons for not wanting them. I think it's good that github has namespaces, but that doesn't mean I think that Cargo should have them, because they're fundamentally different services. The short reason we gave back in 2014 was: > Because namespaces are strictly more complicated in a number of ways,and because they can be added compatibly in the future should they become necessary, we’re going to stick with a single shared namespace. from https://internals.rust-lang.org/t/crates-io-package-policies/1041 https://internals.rust-lang.org/t/crates-io-package-policies... which is linked in the post.
  - mmis1000 6y ago
    But unlike traditional namespace, that you automatically got alias to things inside the same namespace. The npm's namespace is basically just a preserved prefix, mention scoped package inside another scoped package still requires you to write full name (scope + package) or it didn't work. I don't really see a reason that you can't implement it in a flat name package manager? Something like "you can't publish a package named as 'USERNAME_private_WHATEVER' unless you are USERNAME"
    - steveklabnik 6y ago
      Nobody is saying that it's impossible to implement. However, someone would have to write that up as a plan, including all the details, and put it through the RFC process, and get folks to agree that that plan is the one that should be implemented, rather than other possible plans.

AuthorizedCust 6y ago

The article's title is poor. "namespaces in [language name]" should be about the traditional computer science notion of namespaces. A better title may be "No Namespaces in Rust's Package System Is a Feature", although that is long.

dang 6y ago
We edited the title following kibwen's suggestion: https://news.ycombinator.com/item?id=24444812 https://news.ycombinator.com/item?id=24444812

steveklabnik 6y ago

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

krainboltgreene 6y ago
I mean while I absolutely understand the latter situation, the former doesn't feel as understandable because the team could just...make an rfc for it. If you community is clamoring about something, but no one has stepped up to make an RFC for the situation, you have to do two things: 1. Make an RFC for the clamor 2. Figure out why no one has done this already As you know, the lack of response is as much a response as any response.
- steveklabnik 6y ago
  "Make an RFC" means coming up with a comprehensive plan for implementing the feature. If the team says "hey we're not sure we've ever seen a plan that addresses our problems," then it's not really their job to figure out how to address those problems, it's the people who actually want the feature. That may be the team, of course, if they think that it is important enough to pursue. There are people who actively do not want it too, and you can't forget about them. The way you've written this sorta suggests that everyone but the team wants this thing, but the team is ignoring them, but that is very much not the case. It's just a contentious issue with tons of people on every possible side. There are more than two! Also, characterizing it as "no response" is not accurate, as I said, people have not come up with proposals that addressed concerns. It hasn't been ignored. Just not every person has the ability to comment on every thread in every forum. And there have been some people who have put forward proposals. There's an open RFC I linked downthread about a related problem, "crate name transfer," and there was an RFC that was opened two weeks ago, but the person closed it rather than respond to the team's feedback. That there haven't been successful proposals is different than "there have been no proposals." Personally, I think that we haven't had movement because it is an incredibly complicated space, with a ton of overlapping desires, and a lot of complexity, and a lot of angry, low-signal discourse. That nobody wants to wade through all of it isn't surprising. I'm glad this blog post was created; it's the exact kind of work that needs to be done to get things moving in a positive direction.

wnevets 6y ago

is there a TL;DR for why some people don't want namespaces for crates? Is it just because NPM does and javascript is bad or is there something else I'm missing? I couldn't imagine github or npm working well without them.

steveklabnik 6y ago
> Is it just because NPM does and javascript is bad Not at all! In fact, npm's implementation is why some are pro, but also why some say that it's not worth it; see https://news.ycombinator.com/item?id=24444852 https://news.ycombinator.com/item?id=24444852 for some npm specific sentiment. (Incidentally, npm added scoped packages in 2015, after these decisions were made for crates.io. However, crates.io is still smaller than npm was then...) There isn't really a TL;DR because this space is complex, and there's a lot of details, and they matter, and different people have different reasons for not wanting them. I think it's good that github has namespaces, but that doesn't mean I think that Cargo should have them, because they're fundamentally different services. The short reason we gave back in 2014 was: > Because namespaces are strictly more complicated in a number of ways,and because they can be added compatibly in the future should they become necessary, we’re going to stick with a single shared namespace. from https://internals.rust-lang.org/t/crates-io-package-policies/1041 https://internals.rust-lang.org/t/crates-io-package-policies... which is linked in the post.
- mmis1000 6y ago
  But unlike traditional namespace, that you automatically got alias to things inside the same namespace. The npm's namespace is basically just a preserved prefix, mention scoped package inside another scoped package still requires you to write full name (scope + package) or it didn't work. I don't really see a reason that you can't implement it in a flat name package manager? Something like "you can't publish a package named as 'USERNAME_private_WHATEVER' unless you are USERNAME"
  - steveklabnik 6y ago
    Nobody is saying that it's impossible to implement. However, someone would have to write that up as a plan, including all the details, and put it through the RFC process, and get folks to agree that that plan is the one that should be implemented, rather than other possible plans.