Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow renaming crates in the dependencies section #1311

Closed
alexchandel opened this issue Feb 14, 2015 · 18 comments
Closed

Allow renaming crates in the dependencies section #1311

alexchandel opened this issue Feb 14, 2015 · 18 comments
Labels
A-configuration Area: cargo config files and env vars

Comments

@alexchandel
Copy link

Something like this should work:

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

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

@tomjakubowski
Copy link
Contributor

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

[dependencies]
rustc-serialize = "*"

@alexcrichton
Copy link
Member

This is actually currently possible as:

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

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

@alexchandel
Copy link
Author

@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 alexcrichton reopened this Feb 23, 2015
@alexcrichton alexcrichton changed the title Allow specifying crates.io packages in a dependency section Allow renaming crates in the dependencies section Feb 23, 2015
@alexcrichton
Copy link
Member

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

@alexcrichton alexcrichton added the A-configuration Area: cargo config files and env vars label Feb 23, 2015
@alexchandel
Copy link
Author

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
Copy link
Member

bluss commented Mar 11, 2016

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
Copy link
Member

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

@bluss
Copy link
Member

bluss commented Mar 11, 2016

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

@retep998
Copy link
Member

retep998 commented Sep 2, 2016

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
Copy link

evmar commented Jan 31, 2018

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
Copy link
Contributor

alexreg commented Feb 8, 2018

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
Copy link
Member

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

@alexreg
Copy link
Contributor

alexreg commented Feb 8, 2018

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

bors added a commit that referenced this issue Feb 19, 2018
Implement renaming dependencies in the manifest

This commit implements a new unstable feature for manifests which allows
renaming a crate when depending on it. For example you can do:

```toml
cargo-features = ["dependencies-as"]

...

[dependencies]
foo = "0.1"
bar = { version = "0.1", registry = "custom", package = "foo" }
baz = { git = "https://github.com/foo/bar", package = "foo" }
```

Here three crates will be imported but they'll be made available to the Rust
source code via the names `foo` (crates.io), `bar` (the custom registry), and
`baz` (the git dependency). The *package* name, however, will be `foo` for all
of them. In other words the git repository here would be searched for a crate
called `foo`. For example:

```rust
extern crate foo; // crates.io
extern crate bar; // registry `custom`
extern crate baz; // git repository
```

The intention here is to enable a few use cases:

* Enable depending on the same named crate from different registries
* Allow depending on multiple versions of a crate from one registry
* Removing the need for `extern crate foo as bar` syntactically in Rust source

Currently I don't think we're ready to stabilize this so it's just a nightly
feature, but I'm hoping we can continue to iterate on it!

cc #1311
@alexreg
Copy link
Contributor

alexreg commented Feb 28, 2018

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

@alexcrichton
Copy link
Member

Indeed!

@dragostis
Copy link

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
Copy link
Member

matklad commented Apr 24, 2018

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

@dragostis
Copy link

cc #5413

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-configuration Area: cargo config files and env vars
Projects
None yet
Development

No branches or pull requests

9 participants