Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

121–130 of 198 posts

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

#121
post #72

I'm sorry but a language that has data entropy and link rot built into its compiler is not appealing to me. I prefer the Go approach which lets you host or import packages via a HTTP or git URI. If you have to have packaging built-in to the standard toolchain these days, then please use already well-known and existing protocols like DNS and git. Java also figured this out years ago (com.sun... etc).

crates.io is package repository, cargo is a build tool, rustc is the compiler, and they all three are separate entities. rustc as far as I know operates solely on local files, and has no built-in logic or knowledge about crates.io. And cargo can be configured to use different repository than crates.io, which can have different naming policy

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

#122

Earlier quoted context omitted.

> The only alternative to arbitrating your own identity layer is to tie yourself to some other preexisting identity layer (e.g. GitHub, DNS) Devolving identity down to DNS has been a really good decision for Go. I'm not sure why everyone doesn't do it. It's like XML namespaces, but actually useful.

> Devolving identity down to DNS has been a really good decision for Go If it works for go, the because go is not old enough. Domain registrations lapse quickly and then someone else can buy them. That's very close to the worst that can happen for trust in packages.

For better or worse, nearly everyone uses github, which also provides second level name spacing.

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

#123

> This is a strike against any namespace system that allows namespace ownership to unexpectedly change. Discontinuous identity has a couple of issues. Hard agree but this has nothing to do with namespaces. This is equally applicable to names in a flat registry. I don't see the point of bringing this up in this article. > there are also real benefits. [...] discourages forks What. How? Why? I guess there's possibly so…

The whole "Continuity" section seems completely red herring and orthogonal to the namespace issue.

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

#124

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

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.

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

#125

Earlier quoted context omitted.

They don't give you access to the account. They tombstone the old one and assign its handle to yours. So you get the other GitHub handle but your account retains its repos, its keys, etc and doesn't get mixed in with the other account. Of course, if they just let you login to the other one that would be crazy business. You'd know the other guy's email for starters. But they don't. It's all perfectly kosher. You just…

Ah, they gave the account name. When you said "asked them for the guy" and "they just gave it to me", I was interpreting it as the guy's contact info and them just giving it to you, which is what was raising red flags for me. Yeah, it's much less problematic if they just let you use the name of a discontinued account (as long as the github single-sign-on stuff keys off an ID and not a name, which I assume it does).

Yeah sorry about that. Though it's funny. You can just scrape folks' repos to get their email anyway. They all include it in commits. Emails are better made public than kept private imho.

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

#126

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

How many of the namespace desiring crate publishers have participated in the RFC process? (But Mr. Dent, the plans were on display.)

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

#127

Earlier quoted context omitted.

> The only alternative to arbitrating your own identity layer is to tie yourself to some other preexisting identity layer (e.g. GitHub, DNS) Devolving identity down to DNS has been a really good decision for Go. I'm not sure why everyone doesn't do it. It's like XML namespaces, but actually useful.

> Devolving identity down to DNS has been a really good decision for Go If it works for go, the because go is not old enough. Domain registrations lapse quickly and then someone else can buy them. That's very close to the worst that can happen for trust in packages.

If you lose your domain, spreading bad software is the least of your concerns. They can reset all email passwords and access every service you’ve ever used.

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

#128
post #78

Earlier quoted context omitted.

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

> why namespaces are just -impossible- As mentioned elsewhere in here, this is a misrepresentation of the issue. The problem is that crates.io is a free, volunteer-run project with zero full-time employees who could be tasked with the drudgery of intervening in naming disputes or managing an identity layer. This is unlike GitHub and unlike "Java" (by which you probably mean Maven Central, which is operated by Sonatyp…

> Solve the funding issue first, and then you can start solving the rest.

Sell namespaces? Or verified namespaces I guess? Checkmark and all.

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

#129

Earlier quoted context omitted.

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

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…

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

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

#130

Earlier quoted context omitted.

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

How many of the namespace desiring crate publishers have participated in the RFC process? (But Mr. Dent, the plans were on display.)

Impossible to say, given that it's not like I have a list of individuals and their specific desires.

The process is open to anyone. I don't recognize the author of this post, but this is a valuable contribution to the process, for example.

Post reply on HN