Allow renaming crates in the dependencies section

[alexchandel]

Something like this should work:

[dependencies.rustc_serialize]
crate = "rustc-serialize"

At the moment, only path and git attributes are supported.

[tomjakubowski]

What's the intent of this? What would it do differently than:

[dependencies]
rustc-serialize = "*"

[alexcrichton]

This is actually currently possible as:

[dependencies.foo]
version = "..."

Although if you mean renaming crates that's a separate issue :)

[alexchandel]

@alexcrichton I do mean renaming crates, please re-open :P

@tomjakubowski It would create a crate named rustc_serialize, which is imported as extern crate rustc_serialize.

[alexcrichton]

(updated with what I believe to be a more accurate title)

[alexchandel]

Sure, this title works. But a side effect of this is to permit the specification of crates.io as the origin of a dependency named in its own subsection (like [dependencies.foo]), as an alternative to git or path, the two currently available fields, no?

[bluss]

This is a wanted feature for the following scenario:

Your crate provides an optional feature named "serde" that enables serde integration.

In the next version you want to depend two crates for the "serde" feature, serde itself and another crate. Renaming the serde dependency would make the serde feature name available to do this transition smoothly.

[alexcrichton]

@bluss that may be better served in the long run by #1286 perhaps?

[bluss]

Yes, it's considering the same kinds of questions I have (but in greater depth).

[retep998]

Someone was trying to depend on both uuid-sys and uuid (both on crates.io), where the name of the library for uuid-sys is actually uuid. This results in two libraries with the same name (but different hash), so doing extern crate uuid; becomes ambiguous. Having a way to rename a dependency would allow for the user to depend on both crates.

[evmar]

Another example: a program that compared gif implementations might want to use both https://github.com/Geal/gif.rs/blob/master/Cargo.toml and https://github.com/PistonDevelopers/image-gif/blob/master/Cargo.toml, both of which claim the name "gif".

[alexreg]

I've been having a think about this lately, and wondering the best way to do this... it seems the crate name (the one used in extern crate, that is) is taken from the crate metadata. Thus, a sensible solution may be to extend rustc with CLI args that specify the renaming map for dependencies? The checking for well-formed names would additionally be done on the rustc side, I presume. Thoughts?

[alexcrichton]

FWIW I have a PR open for this, and any comments would be much appreciated!

[alexreg]

@alexcrichton Doh, I wish I had known sooner! I just implemented it here too. Oh well, at least someone has done it. Thanks.

[alexreg]

@alexcrichton I think this should be closed now that #4953 is merged, no?

[alexcrichton]

Indeed!

[dragostis]

The example in #4953 fails with:

Dependency 'foo' has different source paths depending on the build target. Each dependency must have a single canonical source path irrespective of build target.

[matklad]

@dragostis could you open a separate issue for that, so that this does not fall through the cracks?

[dragostis]

cc #5413