Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

81–90 of 198 posts

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

#81
post #58
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 This is a complete misrepresentation of the issue. Adding namespaces to crates.io is a social problem, not a technical one, because adding them means you now must do the work of arbitrating disputes over an identity layer, which is a job unfit for part-time volunteers, which is all that crates.io has. The only alternative to arbitrating your own id…

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

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

#82
post #58

Earlier quoted context omitted.

> The developers have convinced themselves that they're right on this This is a complete misrepresentation of the issue. Adding namespaces to crates.io is a social problem, not a technical one, because adding them means you now must do the work of arbitrating disputes over an identity layer, which is a job unfit for part-time volunteers, which is all that crates.io has. The only alternative to arbitrating your own id…

I agree with the main thrust of your post, but there is some level of technical problem because the Rust language doesn't support namespaces in crate names themeselves, and so you have to deal with that (or not...) in some capacity too.

I'm also under the impression that the crates.io team was somewhat reluctant to implement this because it was viewed as a potential security risk from a social engineering point-of-view, even if there were people dedicated to it full time.

That said, I'm having a hard time finding the Rust Internals discussion thread, so I can't tell if I'm misremembering somehow.

Edit: Actually, I think this was in context of re-assigning crate names that may have been "squatted", and how making decisions around what amounted to team member's arbitrary decisions around re-assignment could cause issues. Scratch this, please.

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

#83
post #58

Earlier quoted context omitted.

> The developers have convinced themselves that they're right on this This is a complete misrepresentation of the issue. Adding namespaces to crates.io is a social problem, not a technical one, because adding them means you now must do the work of arbitrating disputes over an identity layer, which is a job unfit for part-time volunteers, which is all that crates.io has. The only alternative to arbitrating your own id…

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

Organizations live shorter than packages, just look at all the com.sun stuff in Java. And even in the absence of corporate changes, you may well want to transfer a package to a new home.

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

#84
post #22

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

Ok, we'll use your phrasing above. Thanks!

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

#85

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

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

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

#86
post #66
post #49

Earlier quoted context omitted.

I didn't choose the shorter names because i "care[d] about having shorter names", i did so defensively, because i figured if i chose `net.sekao/iglu`, someone else would choose `iglu/iglu` which would imply that theirs was the original or official version. Another point i didn't mention is that maven was designed from the start to be decentralized; many companies run their own private maven repos, but also pull artif…

That's a better rationale, although I don't think that really solves your stated problem; as an uninformed user I am still more likely to think that iglu/iglu is the more authoritative source there. Given this, any project that wants to authoritatively own its identifier should probably also register its own top-level namespace... which unfortunately brings us back around to where we started.

It would at least be far less of an issue. I don't see anyone being confused that https://github.com/facebook/react is the official repo, and not https://github.com/react/react. It's the fact that a collapsed name is a shortcut that imbues it with this special stature. And i believe maven central doesn't even allow one-segment group names for new libraries, though clojars obviously does.

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

#87
post #58

Earlier quoted context omitted.

> The developers have convinced themselves that they're right on this This is a complete misrepresentation of the issue. Adding namespaces to crates.io is a social problem, not a technical one, because adding them means you now must do the work of arbitrating disputes over an identity layer, which is a job unfit for part-time volunteers, which is all that crates.io has. The only alternative to arbitrating your own id…

> 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

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

To be clear, you can always depend on a package from your own host, or from a git URL, today.

You can also make an alternative registry and add dependencies from that registry.

That said, an alternative registry that enforces namespacing would not work, just because of cargo's limitations on package names that prevent characters like /

It could be done by making every "namespace" a different registry, and for those registries to allow packages with dependencies from other registries (something that crates.io doesn't allow, for a reasonably good reason). Would be quite verbose for the user though.

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

#89
post #14

Earlier quoted context omitted.

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

What's right with package namespaces? How do they help at all? Where's the benifit? The cost is that package paths are longer and hard to remember. Also confusing because multiple packages can have the same name

> 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

Squatting is not a major problem just name your package yourname-xml or randomname instead of yourname.xml

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

#90
post #35
post #5

I remember when this came up because of the following user: https://crates.io/users/swmon

That is horrendous and it should be taken down due to obvious non-fair and possibly malicious intent.

Then packages will be resquatted. Maybe by the same person under different name.
Post reply on HN