Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

161–170 of 198 posts

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

#161

Earlier quoted context omitted.

> "Make an RFC" means coming up with a comprehensive plan for implementing the feature. That directly contradicts your previous comment (that RFCs are the contexts that the teams are supposed to evaluate). Either: 1: non-comprehensive discussions are appropriate for a RFC, and random forum threads are the wrong place for that, in which case your previous comment is absolutely correct that it's unnecessary and likely…

1 is correct, sorta. Comments on an RFC are absolutely fine. That is their purpose. Random forum threads aren't the wrong place for that, like, you can discuss ideas for RFCs on forum threads, but you can't expect the team to always weigh in on threads. Their only responsibility is to the RFC process itself. If you're trying to get a proposal accepted, it's the wrong place. If you're trying to work on a proposal and…

> > that still leaves the question of why they haven't made such a RFC yet.

> Yes. I speculated a bit in my last paragraph.

Sorry, I phrased that poorly; see edit.

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

#162

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.

Not really. Look at the protobuf 'renaming' and think about how silly that is.

Protobuf renaming?

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

#163
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…

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. To be honest, that's an impressive oratory monstrosity you've produced there. No argument, no nothing, and nevertheless it sounds completely brain-shutting-down conclusive. I don't think the rust people are deserving of it. They've done impressive work with minimal…

Respect for a sentence I would expect from my 5 year old?

One of these years I'll understand this place! I just know it!

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

#164
post #95

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…

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.

Maven also does it.

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

#165
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…

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

There is, sort of! Assuming you choose a semi-reasonable timeframe (5? 10 years?), I’d be happy to take the other side on Longbets.

I believe there’s even a reasonable argument to be made that your bet is societally important, as the rules [1] require, based on your final paragraph. Roughly your take is that over time, efforts realize that the naïveté of youth misread the battle scars of what came before. crates.io having namespaces or not is just the mechanism for this debate :)

[1] https://longbets.org/rules/

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

#166

Earlier quoted context omitted.

The quote is from: https://insideclojure.org/2020/07/28/clj-exec/ under section "Deprecated unqualified lib names". That said, ya this is best intentions unfortunately. I'm guessing if you own a real trademark, you could actually sue people using your trademark as their group-id. Otherwise in general they recommend using a registered web domain name. Someone else could take over your domain name as theirs, but I thin…

> maven-central required a form of proof of ownership of the domain They do. There's even a manual review procedure.

Oh really? Wow that's awesome I had no idea maven central did that.

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

#167
If anything, namespacing doesn't go far enough. We have a wonderful namespacing mechanism already for the Internet - it's called DNS. We use DNS validation as a security foundation for issuing TLS certificates. Package registries should allow me to "own a domain" - backed up by DNS validation - and upload packages under that name. "Domain ownership" should be paired to a timestamp issued at verification time, so that a) package uploading can be blocked entirely if the DNS verification is lost, b) consumers can continue to download packages under the old domain timestamp c) domain ownership can still transfer as needed d) changes in ownership are tracked, and consumers are notified.

Why does everybody always have to reinvent the wheel? DNS has been around for decades. Using DNS records to verify ownership has been around since, what, the early days of the ACME protocol in 2014/2015? Earlier?

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

#168
post #95

Earlier quoted context omitted.

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.

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

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"

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

#169

Earlier quoted context omitted.

Not really. Look at the protobuf 'renaming' and think about how silly that is.

Protobuf renaming?

I was referring to this:

https://blog.golang.org/protobuf-apiv2

> The github.com/golang/protobuf module is APIv1.

> The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider.

Basically, Google realized that it's not a good idea to tie your package's identity to GitHub's URL scheme. This is easy for Google to fix, but the majority of Go packages suffer from the same problem, and it is much harder for a small project to start maintaining a DNS record that they control to point that to GitHub.

Not to mention, if GitHub decided to change its URL scheme for some reason, almost all Go builds on the planet would have to change.

And of course, the whole problem stems from relying on DNS to name your packages. No one wants to bother with DNS, so they go for the low effort option and let some hosting provider handle it for them, without caring what happens in 10 years time.

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

#170
post #155

Earlier quoted context omitted.

Crates.io is run by a couple volunteers, they (sadly) don't have the time to start playing cat-and-mouse with squatters.

Why isn't Mozilla funding them?

Mozilla is progressively dropping the rust project has they doesn't have the financial resources anymore
Post reply on HN