Implement renaming dependencies in the manifest #4953

alexcrichton · 2018-01-17T19:40:33Z

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

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:

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

rust-highfive · 2018-01-17T19:40:36Z

r? @matklad

(rust_highfive has picked a reviewer for you, use r? to override)

sfackler · 2018-01-17T19:45:22Z

This may have already been discussed elsewhere, but I think it would be a bit less confusing to do something like this:

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

It avoids the extra array, and makes it so that the set of names you're importing (modulo crate/lib naming differences) are all in the same place.

alexcrichton · 2018-01-17T19:55:26Z

Heh that's actually the first syntax I thought of as well, although it was changed due to rust-lang/rfcs#2126 (comment), namely:

the desired crate alias as the leading key in Cargo.toml conflates packages and crates (a common conflation that we should probably work on separately).

For example today you actually specify package names as the key in [dependencies] whereas the as/alias business we want is to rename the crate. (it's possible for packages to be named differently from their library crate).

That being said I also just realized something that can be troubling. How, for example, do we enable features for these dependencies? For example:

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

[features]
some-feature = ["foo/another-feature"] # what version of `foo`?

This I think is much clearer with what @sfackler is thinking:

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

[features]
some-feature = ["foo/another-feature"] # aha, the crates.io version!

That may tip my own opinion towards the latter!

sfackler · 2018-01-17T19:57:16Z

Oh yeah, good point. It's too bad you're allowed to set the library name separately from the crate name :(

matklad · 2018-01-19T11:51:28Z

src/cargo/core/features.rs

@@ -125,6 +125,9 @@ features! {

        // Downloading packages from alternative registry indexes.
        [unstable] alternative_registries: bool,
+
+        // Downloading packages from alternative registry indexes.


Wrong comment

matklad · 2018-01-19T11:54:01Z

src/cargo/ops/cargo_rustc/mod.rs

+                .filter_map(|d| d.rename())
+                .next();
+
+            v.push(name.unwrap_or(&dep.target.crate_name()));


Could we make this .unwrap_or an utility method of something? Like fn crate_name(&self) -> String, which deals with as and, probably, with translating - to _ as well.

matklad · 2018-01-19T11:57:55Z

tests/rename-deps.rs

+            bar = [
+                { version = "0.1.0" },
+                { version = "0.2.0", as = "baz" },
+            ]


Hm the syntax does not look too natural to me. Is the following a valid TOML?

[dependencies] bar = "0.1.0" bar = { version = "0.2.0", as = "baz"}

Unfortunately TOML-the-spec doesn't allow for something like that b/c it's counted as a redefinition of an existing key :(

bors · 2018-01-20T07:46:01Z

☔ The latest upstream changes (presumably #4844) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2018-01-25T01:50:02Z

☔ The latest upstream changes (presumably #4957) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2018-02-06T19:40:43Z

☔ The latest upstream changes (presumably #5011) made this pull request unmergeable. Please resolve the merge conflicts.

retep998 · 2018-02-08T22:39:12Z

If we wanted to make it clear where we're specifying the package name vs the crate name, perhaps we could do something like...

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

[features]
some-feature = ["foo/another-feature"] # aha, the crates.io version!

alexreg · 2018-02-08T23:43:29Z

@alexcrichton Great work on this. I think this feature is very much due. Funnily enough, I was just going to suggest the key package (or pkg), but @retep998 just beat me to it. The semantics would be changed from your original approach, and the current method, with keys now representing user-facing crate names rather than package names, but it would at least be operationally backwards-compatible (in the case of no package value, that is). In other words, the value of the package field would default to the user-facing crate name (i.e. alias). This seems quite nice to me.

It's also worth noting that this PR helps with rust-lang/rust#44660.

Finally, maybe add a "fixes #1311" to your original PR message?

alexcrichton · 2018-02-12T18:08:44Z

I've updated with the feedback so far (and switched to the non-array syntax using a package key), re-r? @matklad

@alexreg oh we typically like to keep the issues open to track the feature, but I should have cc'd it in the original message for sure!

alexreg · 2018-02-12T18:11:10Z

@alexcrichton Yeah, that's fair enough. Anyway, the new semantics are with the alias on the LHS of the =, right? (i.e. what I elaborated on above.)

alexcrichton · 2018-02-12T19:16:10Z

@alexreg, correct!

alexreg · 2018-02-12T19:26:49Z

Super. Hopefully @matklad can review soon and then we can get this merged.

matklad

Here are a couple of tests I think we could add

Using exactly the same library twice. This presumably should be an error
Renaming a package whose library name does not match the package namme

matklad · 2018-02-12T19:58:05Z

src/cargo/core/dependency.rs

@@ -27,6 +27,7 @@ struct Inner {
    specified_req: bool,
    kind: Kind,
    only_match_name: bool,
+    rename: Option<String>,


I'd call it package, to be consistent with the package in the surface syntax, and to make it more clear in which direction renaming goes (I.e, in theory you can have a crate foo which is renamed to pacakge baz, or, the other way around, a package baz which is renamed to crate foo).

Oh this is slightly different through b/c it's not actually the package, but rather what the dependency is renaming the crate to

Yeah, even though there's a one-to-one correspondence with the package attribute, rename probably makes more sense in code (perhaps with a comment?)... that's my thought, anyway.

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!

alexcrichton · 2018-02-12T23:16:40Z

@matklad sure yeah, although for specifying one crate twice we're already pretty bad about that today unfortunately. For example something like:

[dependencies]
foo = "0.1"

[target.'cfg(unix)'.dependencies]
foo = "0.1"

is accepted and works, so I figure we can probably just let rustc sort it out if it's specified multiple times.

matklad · 2018-02-19T20:00:06Z

@bors r+

bors · 2018-02-19T20:00:06Z

📌 Commit 79942fe has been approved by matklad

alexreg · 2018-02-19T20:06:12Z

Good work with this @alexcrichton! Thanks. 👍🏻

bors · 2018-02-19T20:21:31Z

⌛ Testing commit 79942fe with merge 4f1c6db...

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

bors · 2018-02-19T21:09:45Z

☀️ Test successful - status-appveyor, status-travis
Approved by: matklad
Pushing 4f1c6db to master...

aaronsky · 2018-07-21T14:58:18Z

With this merged, does this mean that the item under rust-lang/rust#44931 should be updated? Apologies if this is the wrong place to ask about this

alexreg · 2018-07-21T16:31:27Z

@aaronsky Yep, it should be. Maybe ping @aturon on that thread to update the checkbox(es). :-)

aldanor · 2018-11-15T20:54:06Z

Here's a curious (but not so improbable) edge case with proc macros. Wondering how should this be handled? (or am I misunderstanding something)

There's three crates, foo, foo-derive and bar
foo-derive is a proc-macro crate which depends on crate foo (without any renaming) and mentions ::foo::Foo in the resulting token stream
bar is a top-level crate that depends on both foo and foo-derive
Using the rename feature, in bar's manifest we have baz = { package = "foo" }

Now, if we use the derive proc macro in crate bar, it seems to be broken upon use, like so:

^^^^^^ Could not find `foo` in `{{root}}`

What would be a proper way to refer to it then?..

aldanor · 2018-11-15T23:21:58Z

Here's a concrete example, using num-derive.

Cargo.toml:

cargo-features = ["rename-dependency"]

[package]
name = "rename-test"
version = "0.1.0"
edition = "2018"

[dependencies]
foo = { package = "num-traits", version = "0.2" }
num-derive = "0.2"

src/lib.rs:

use num_derive::{FromPrimitive, ToPrimitive};

#[derive(FromPrimitive, ToPrimitive)]
enum Color { Red, Blue, Green }

... which results in...

error[E0463]: can't find crate for `_num_traits`
 --> src/lib.rs:3:25
  |
3 | #[derive(FromPrimitive, ToPrimitive)]
  |                         ^^^^^^^^^^^ can't find crate

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.

alexcrichton · 2018-11-16T08:09:43Z

@aldanor that's a general problem with hygiene and procedural macros, and most procedural macros only work if the corresponding library crate is imported with one precise name (and not renamed). There's no way, for example, to get importing the serde crate under a different name to work with its derive modes.

aldanor · 2018-11-16T08:22:25Z

@alexcrichton Yea, I understand (and this is quite sad because most derive macros depend on some other crate; maybe there should be some crate-resolving syntax like $crate(num-traits)?.. This will keep being an annoying problem in the future. This is out of scope of this PR though).

With the example above though, if you revert back to 2015-edition way and remove renaming from the manifest, it does work with

[dependencies]
num-traits = "0.2"
num-derive = "0.2"

and

extern crate num_traits as foo;  // <--
#[macro_use] extern crate num_derive;

#[derive(FromPrimitive, ToPrimitive)]
enum Color { Red, Blue, Green }

(because of extern crate num_traits as _num_traits line in the macro itself)

Does it mean this particular case is a rename-dependency regression then?

alexcrichton · 2018-11-16T09:23:00Z

I don't think this is really a regression, you can always remove renaming in the manifest and have use foo as bar; in the code. The usability annoyance would be fixed with a better form of hygiene in procedural macros, and there's not much that Cargo itself can do

ehuss · 2018-11-16T16:13:29Z

maybe there should be some crate-resolving syntax

There is an issue open for this at rust-lang/rust#54363.

updogliu · 2019-05-08T14:30:56Z

Can this enable depending on the same version of a crate but using conflicting features at the same time (with different renaming of course)?

ehuss · 2019-05-08T15:41:13Z

@updogliu A package cannot have two dependencies to the same version of a crate.

updogliu · 2019-05-08T16:07:57Z

@ehuss What I am trying to achieve is using a crate of the same version but with conflicting features in two members of a workspace. Is that a valid motivation?

ehuss · 2019-05-08T16:30:09Z

If the two members are built separately, then they will each use a different copy of the dependent crate (with different features activated). If the two members are being linked together, then it will unify the features and use a single copy. Conflicting or mutually exclusive features aren't really supported. There are a number of issues in the tracker here to make this more flexible, but we're still in the design phase.

updogliu · 2019-05-09T00:56:38Z

@ehuss I have an example at here. There are three members in a workspace: foo, bar, common. foo and bar do not depend on each other, but they both depend on common and using mutually exclusive features. Is this kind of use to be supported or not?

retep998 · 2019-05-09T04:24:03Z

Mutually exclusive features are not supported.

updogliu · 2019-05-09T05:57:57Z

@retep998 I understand that it is currently not supported. But since this nice renaming dependencies feature is added to support using different versions of a crate, maybe it can be augmented a bit to support exclusive features under different renaming as well?

burdges · 2019-08-13T07:34:10Z

I presume cargo features only work on nightly installs

rust-highfive assigned matklad Jan 17, 2018

matklad reviewed Jan 19, 2018

View reviewed changes

alexcrichton force-pushed the rename-via-as branch from 0addcd2 to 6e90f36 Compare January 22, 2018 04:48

alexcrichton force-pushed the rename-via-as branch from 6e90f36 to 102ee8a Compare January 25, 2018 16:35

alexcrichton mentioned this pull request Feb 8, 2018

Allow renaming crates in the dependencies section #1311

Closed

alexcrichton force-pushed the rename-via-as branch from 102ee8a to 3d7dcdf Compare February 12, 2018 18:07

matklad reviewed Feb 12, 2018

View reviewed changes

alexcrichton force-pushed the rename-via-as branch from 3d7dcdf to 79942fe Compare February 12, 2018 23:15

bors merged commit 79942fe into rust-lang:master Feb 19, 2018

alexcrichton mentioned this pull request Apr 27, 2018

Tracking issue for renaming crate dependencies #5422

Closed

astraw mentioned this pull request Apr 29, 2018

remove use of futures and tokio from within client adnanademovic/xml-rpc-rs#1

Merged

jonhoo mentioned this pull request May 16, 2018

Use correct name when dependency has been renamed kbknapp/cargo-outdated#133

Closed

dekellum mentioned this pull request Jun 1, 2018

cargo dependency rename breaks cargo-tree sfackler/cargo-tree#38

Closed

matklad mentioned this pull request Jun 26, 2018

Renaming dependencies in Cargo.toml #5653

Closed

4 tasks

hannobraun mentioned this pull request Oct 11, 2018

[RFC] Managing breaking changes to existing traits rust-embedded/embedded-hal#100

Closed

dtolnay mentioned this pull request Oct 25, 2018

Expose dependency renames so that enabled features make sense rust-lang/crates.io#1539

Open

aldanor unassigned matklad Nov 15, 2018

clintfred mentioned this pull request Jul 23, 2019

Update to rand 0.7 IronCoreLabs/recrypt-rs#84

Closed

This was referenced Aug 11, 2019

Any shim rand_core 4.3 crate around rand_core 0.5? rust-random/rand#865

Closed

no_std is broken, doesn't play with sgx w3f/schnorrkel#31

Open

DerLando mentioned this pull request Feb 1, 2020

Implements first draft of quadtree lookup implemented via *BoundingBox* Michael-F-Bryan/arcs#12

Merged

ehuss added this to the 1.26.0 milestone Feb 6, 2022

Implement renaming dependencies in the manifest #4953

Implement renaming dependencies in the manifest #4953

Conversation

alexcrichton commented Jan 17, 2018 • edited Loading

rust-highfive commented Jan 17, 2018

sfackler commented Jan 17, 2018

alexcrichton commented Jan 17, 2018 • edited Loading

sfackler commented Jan 17, 2018

matklad Jan 19, 2018

Choose a reason for hiding this comment

matklad Jan 19, 2018

Choose a reason for hiding this comment

matklad Jan 19, 2018

Choose a reason for hiding this comment

alexcrichton Jan 19, 2018

Choose a reason for hiding this comment

bors commented Jan 20, 2018

bors commented Jan 25, 2018

bors commented Feb 6, 2018

retep998 commented Feb 8, 2018

alexreg commented Feb 8, 2018

alexcrichton commented Feb 12, 2018

alexreg commented Feb 12, 2018

alexcrichton commented Feb 12, 2018

alexreg commented Feb 12, 2018

matklad left a comment

Choose a reason for hiding this comment

matklad Feb 12, 2018

Choose a reason for hiding this comment

alexcrichton Feb 12, 2018

Choose a reason for hiding this comment

alexreg Feb 13, 2018

Choose a reason for hiding this comment

alexcrichton commented Feb 12, 2018

matklad commented Feb 19, 2018

bors commented Feb 19, 2018

alexreg commented Feb 19, 2018

bors commented Feb 19, 2018

bors commented Feb 19, 2018

aaronsky commented Jul 21, 2018 • edited Loading

alexreg commented Jul 21, 2018

aldanor commented Nov 15, 2018 • edited Loading

aldanor commented Nov 15, 2018 • edited Loading

alexcrichton commented Nov 16, 2018

aldanor commented Nov 16, 2018 • edited Loading

alexcrichton commented Nov 16, 2018

ehuss commented Nov 16, 2018

updogliu commented May 8, 2019

ehuss commented May 8, 2019

updogliu commented May 8, 2019

ehuss commented May 8, 2019

updogliu commented May 9, 2019

retep998 commented May 9, 2019

updogliu commented May 9, 2019

burdges commented Aug 13, 2019

alexcrichton commented Jan 17, 2018 •

edited

Loading

alexcrichton commented Jan 17, 2018 •

edited

Loading

aaronsky commented Jul 21, 2018 •

edited

Loading

aldanor commented Nov 15, 2018 •

edited

Loading

aldanor commented Nov 15, 2018 •

edited

Loading

aldanor commented Nov 16, 2018 •

edited

Loading