Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

Post reply on HN
Print view View original

71–80 of 198 posts

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

#71

Post by kibwen »

steveklabnik wrote: post #62
kibwen wrote: 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.

Obviously we're all talking hypotheticals here, but Rust-the-language doesn't need to support crate-level namespaces (which isn't to say that some first-class support couldn't be imagined, but again: hypotheticals). Rust links to libraries (via explicit or implicit `extern crate`) that it finds on the system via the ordinary OS-level library search path mechanism; it's up to the package manager to put those libraries on the system in a place (and with a name!) where Rust can find them. As long as the package manager can turn the registry namespaces into something usable from Rust, then there's no need to add anything to the language itself. A package manager could decide to put a namespaced package "foo/bar" on the system as merely "bar", and require the user to manually disambiguate when colliding (using ordinary rename rules, such as is already supported by Cargo). Alternatively, a registry could forbid uploading packages whose names internally contain underscores, and then the package manager could install "foo/bar" as a crate "foo_bar", which has no risk of collision (well, with packages from that registry).

This is why the conflation in the title of the OP here is especially annoying; package management is a concern that the language doesn't necessarily benefit from being aware of, hence the separation of the compiler and the package manager. :)

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

#72

Post by zelly »

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

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

#73

Post by steveklabnik »

kibwen wrote: post #71
steveklabnik wrote: post #62

Earlier quoted context omitted.

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.

Obviously we're all talking hypotheticals here, but Rust-the-language doesn't need to support crate-level namespaces (which isn't to say that some first-class support couldn't be imagined, but again: hypotheticals). Rust links to libraries (via explicit or implicit `extern crate`) that it finds on the system via the ordinary OS-level library search path mechanism; it's up to the package manager to put those libraries…

> As long as the package manager can turn the registry namespaces into something usable from Rust,

All I am trying to say is that this is a technical problem, in addition to the larger problems, which you correctly identified are social.

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

#74

Post by steveklabnik »

zelly wrote: 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.

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

#75

Post by hyperman1 »

013a wrote: 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 resources, and they have shown the ability to create consensus that's better than any of the individual parts that contribute to it. So I'm going to trust them in this for now, and maybe, they'll evolve in the future.

Nevertheless, I have to admit respect for that sentence, in the same sense I'll admit respect for an earth-shattering nuclear explosion. You might want to run for US president if you produce more of them, though I'm not sure if that's praise or damnation.

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

#76

Post by est31 »

kibwen wrote: post #71
steveklabnik wrote: post #62

Earlier quoted context omitted.

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.

Obviously we're all talking hypotheticals here, but Rust-the-language doesn't need to support crate-level namespaces (which isn't to say that some first-class support couldn't be imagined, but again: hypotheticals). Rust links to libraries (via explicit or implicit `extern crate`) that it finds on the system via the ordinary OS-level library search path mechanism; it's up to the package manager to put those libraries…

> Rust links to libraries (via explicit or implicit `extern crate`) that it finds on the system via the ordinary OS-level library search path mechanism

Nit: rustc gets passed each crate available to be used or extern crate via an --extern flag that specifies the name of the crate as well as the full path. The path is optional and if not specified rustc performs a search, but the name is mandatory. Cargo only uses the mode with both path and name specified. This also isn't an edition 2018 thing, it exists on older cargo versions too. It's possible to specify the same file under multiple names, then it's available to Rust programs under multiple names. It's also possible to specify multiple paths for the same name, but then only one will be taken, the first one which is available.

Also, note that Cargo works in terms of packages, and rustc in terms of crates. A package can contain up to one library crate, and the names of the two don't have to match.

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

#77

Post by masklinn »

simon_o wrote: post #20
raphlinus wrote: post #8

Earlier quoted context omitted.

Also https://crates.io/users/tony-iqlusion That person is definitely not helping the perception that a significant fraction of the cryptofinance community is scammers, and that their presence has a negative effect on the community.

Oh wow ... that guy ... is also doing this? That certainly puts his participation in the namespacing debates into a new light.

That account is weirder though, they have a bunch of real (and real popular) projects like zeroise, the filled-in projects are rather complex, and even the placeholder packages have a somewhat proper description, though some of them are very very odd.

They're not out there hawking popular names for sale and some of their placeholders are even "namespaced" (the abscissa or signatory subcomponents).

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

#78

Post by kibwen »

andrewzah wrote: post #29
kzrdude wrote: 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,…

> 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 Sonatype). Solve the funding issue first, and then you can start solving the rest.

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

#79

Post by dnautics »

013a wrote: post #70
computerphage wrote: post #46

Earlier quoted context omitted.

> 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. This sentence takes the place of a reason. You could have offered a reason why you were right or a rational argument about the matter. Instead, you basically yelled "I'm right, they're wrong! I'm right, they're wrong!".

I am not arguing that this should happen; I am asserting that this will happen. The reasons why it should or shouldn't happen don't matter when it will happen. If you'd like to: Go back and re-read my comment, but re-read it in the mindframe that I'm against the change. It still holds. I didn't provide reasons why they should make the change, because I don't have a stance on whether they should or shouldn't. I am not…

You have to admit the possibility that people will give up on rust before it happens (possibly because of this issue).

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

#80

Post by hyperman1 »

setr wrote: post #13
gw wrote: post #4

You really should look to other ecosystems and see what lessons they've learned. In java, packages are normally "namespaced" by the author's reverse domain name, like `org.lwjgl/lwjgl`. Since clojure uses maven as well, the same applies, but clojure tools like leiningen decided to create a shortcut: if the group and artifact name are the same, like `iglu/iglu`, they can be collapsed into one name: `iglu` Well, that j…

>Forks are inevitable; why would you want to discourage them? The epitome of this mindset I think is "hostile fork" -- the entire notion is nonsensical. The whole point of being FOSS/OSS is the freedom to fork -- by all damn rights, you should fork as you please, and be pleased to fork! The actual problem is not forking.. its community fragmentation, and more importantly loss of a "source of truth". Of course, mainta…

This was discussed in detail in Homesteading the Noosphere of Eric S Raymond.

I think it's in there somewhere that he compares the right to fork with the right to bear arms: Good to have, but the situation must have gotten really shitty if a fork is a good solution.

https://firstmonday.org/ojs/index.php/fm/article/download/14...

Post reply on HN