Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: