Small idea: totally not crates.io namespacing

1

What if Cargo allowed you to write one "/ " in the name of a dependency? When resolving the dependency's name, it replaces it with "-". When choosing the rustc-visible name of the resulting library, it drops it and everything before it.

I recently started a pet project that, for reasons, is divided into lots of crates. In order to not pull a WindowsBunny in the event I publish this on crates.io, it uses crate names like remu-nintendo-dmg-01 and remu-sharp-lr35902, which are long and annoying. I'd much rather use dmg-01 and lr35902, but no, I'm not here to beat this dead horse.

Anyway, it occurred to me that the real problem here is that I want a nice, long, fully-qualified name for the global crate index, but I want a short name without all the (90% of the time) superfluous gunk when I'm actually using it, and without the need to incessantly rename the crate everywhere I use it (which was part of the reason I argued against the special case for "-" in crate names).

So... what if Cargo understood a short-hand syntax for renaming crates within the manifest that gives us both? Let's say I changed the dependencies for the above into "remu-nintendo/dmg-01" and "remu-sharp/lr35902". Rust itself would see them as dmg_01 and lr35902: nice and short. crates.io would see them as remu-nintendo-dmg-01 and remu-sharp-lr35902.

I think this would be good to have because it encourages people to "fake namespace" their crates in a way that avoids the inconvenience of the long names in code. Collections of crates like imag, imag-store, imag-tag, etc., or piston2d-* are more usable and less repetitive, and it lowers the incentives for unprefixed crate spamming.

Don't get me wrong, I still think Cargo should let me rename dependencies from the manifest arbitrarily, but this seems like a broad, common case.

2 Likes
2

What happens if I depend on a/foobar and b/foobar?

3

I would actually like to let the owner of a crate upload crates nested under it 1 level deep, so when you've broken up a project into multiple crates you can keep them under that name's unambiguous "branding," and cargo could build features with an awareness of the relationship between those crates.

3 Likes
4

This is already possible, by the way, though not recommended. The name of the package is not required to match that of the crate. See the name field of the lib section Page Moved

5

About the same as if you do extern crate a_foobar as foobar; extern crate b_foobar as foobar;

I know. The problem is that, once again, because Cargo won't let you rename crates at the manifest level, this is a really bad idea. The advantage of letting the user define where to cut the name is that we start from a position of "there are no name collisions", and can simplify the names from there.

I mean, if you started with a dependency on a/foobar, it'd be up to the user to decide if they want the crates to be exposed in code as foobar and b_foobar, or a_foobar and b_foobar. For the majority of cases, the shortened name would probably be just fine.

Yes, me too, but...

6

How about:

[dependencies]
DanielKeep/banana = "1.0"
sfackler/banana = "1.2"

$ cargo build
Error: ambiguous crate names: DanielKeep/banana, sfackler/banana. Apply a `rust_name` to one or both of the packages

[dependencies]
DanielKeep/banana = version="1.0"
sflackler/banana = {rust_name="sfbanana", version="1.2" }
7

Like I said, I do want renaming... but sfackler_banana works in the interim, too, and I figured this idea has more potential the simpler it is.

8

Or more simply:

[dependencies]
DanielKeep_banana = "1.0"
sfackler_banana = "1.2"
9

I'd prefer explicit syntax for renaming instead of implicit magic .. even if that means a little more typing in Cargo.toml

2 Likes