Add the ability to rename a crate inherited from the workspace

[fluiderson]

Problem

Consider the following part with workspace dependencies from root Cargo.toml:

[workspace.dependencies]
itoa = "1"
itoa-old = { version = "0.4", package = "itoa" }

And parts with dependencies from 2 workspace members:

# member-1/Cargo.toml
[dependencies]
itoa.workspace = true

# member-2/Cargo.toml
[dependencies]
itoa = { workspace = true, package = "itoa-old" }

Before checking/compiling member-2, Cargo prints this warning:

warning: /home/user/ws/member-2/Cargo.toml: unused manifest key: dependencies.itoa.package

And hence ignores the package key from member-2's Cargo.toml.

So, unless I missed something in the documentation, Cargo can't rename dependencies inherited from the workspace.

Proposed Solution

Make Cargo read the package key in inherited dependencies, and rename them as it does with usual dependencies.

Notes

No response

[epage]

When renaming, in addition to the dependency name, you specify a package of a different name. What I'm not too sure about is taking the package field and treating it as a dependency name to look up the actual package name.

[fluiderson]

I mean, in the case of an inherited dependency, Cargo could use the package field as a pointer to the package name in the workspace, not to the actual package name.

Something like this:

flowchart RL
    subgraph Workspace
    itoa-old -- "package = #quot;itoa#quot;" --> itoaN[itoa 0.4]
    end
    subgraph member-2
    itoa -- "package = #quot;itoa-old#quot;" --> itoa-old
    end

Loading

[epage]

My concern is that that isn't the package's name in the workspace but a dependency's name and I feel a little uncomfortable co-mingling the two.

[VlaDexa]

It's not necessary to mingle the names, the problem is that you can't rename the crates at all, if you are trying to inherit them from the workspace.

[real-felix]

I have a related issue (I think). I have a bunch of crates in my workspace:

# ./Cargo.toml
foo = { git = "https://github.com/awasome/qux", branch = "master" }
bar = { git = "https://github.com/awasome/qux", branch = "master" }

Then in a crate:

# ./my-crate/Cargo.toml
bar = { package = "cool-bar", workspace = true }

But the current cargo won't accept this.

I'm ready to having a try at this, if it's not too hard for a newcomer. I assume it's not, it's should be fairly simple to add, right?

[fluiderson]

Yes, it may be simple, but I guess this change should've a better design. As was stated above, using the package field for referencing not only the actual package name but also the name of a dependency may be confusing. Perhaps we can introduce a new field? Something like:

[dependencies]
itoa = { workspace = true, name = "itoa-old" }

And @Boiethios, seems like bar & cool-bar in your second listing should be swapped.

[epage]

Haven't thought this through but one idea

[dependencies]
itoa = { workspace = "itoa-old" }

[avkonst]

Haven't thought this through but one idea

[dependencies]
itoa = { workspace = "itoa-old" }

This is what I tried without checking docs, assuming it works as expected. But it did not :(

[avkonst]

Can this solution be applied and merged? #12546 (comment)

[fluiderson]

I can try to implement this, but someone from the team should approve this design first.

[avkonst]

Do you know who to ping from the design team?

[fluiderson]

@epage?

[epage]

If you want to see the relevant team, it is here (yes, I'm on it).

My idea was just for brainstorming purposes. People immediately jumped on it without giving it any critical thought. That critical thought is what is needed to drive this forward. In thinking about this a bit more, I at least would first want to see what other needs we come up with for workspace inheritance to make sure we don't design ourselves into a corner, Here, we propose making workspace accept a dependency name but could we want another meaning from that more generally? Its too early to say.

Example future expansions that could possibly get in the way

• Workspace inheritance
• Named groups of inheritable content (rather than monolithic inheritable content)
• Other fields needing slightly different specialization and the two not playing well together

I would also be interested in any thoughts from @Muscraft considering they've put a lot of thought into this since they worked on it.