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).
The lack of namespaces on crates.io is a feature
121–130 of 198 posts
Re: The lack of namespaces on crates.io is a feature
#122Earlier 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.
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…
Re: The lack of namespaces on crates.io is a feature
#124For 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…
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
#125Earlier 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).
Re: The lack of namespaces on crates.io is a feature
#126For 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…
Re: The lack of namespaces on crates.io is a feature
#127Earlier 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.
Re: The lack of namespaces on crates.io is a feature
#128Earlier 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…
Sell namespaces? Or verified namespaces I guess? Checkmark and all.
Re: The lack of namespaces on crates.io is a feature
#129Earlier 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…
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
#130Earlier 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.)
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.