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

[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? https://github.com/rust-lang/cargo/issues/12546#issuecomment-1730073953

[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.

[epage]

btw the obvious workaround for this is to just use the rename within your package (I assume that works)

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

For people pressing this, the most relevant information would be why the workaround is not sufficient in your specific case.

[avkonst]

Sorry, what workaround do you mean by rename within your package?

On Tue, 17 Oct 2023, 03:11 Ed Page, @.***> wrote:

btw the obvious workaround for this is to just use the rename within your package (I assume that works)

member-2/Cargo.toml

[dependencies]itoa-old.workspace = true

For people pressing this, the most relevant information would be why the workaround is not sufficient in your specific case.

— Reply to this email directly, view it on GitHub https://github.com/rust-lang/cargo/issues/12546#issuecomment-1764570239, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6JSVLZCTJK7FATQENCNA3X7U6BZAVCNFSM6AAAAAA34ADKKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRUGU3TAMRTHE . You are receiving this because you commented.Message ID: @.***>

[codewing]

I've also stumbled upon this issue today where we have different versions i.e. mycrate_v1 and mycrate_v2 and in most crates we directly refer to them by name but some other times we want to simply specify mycrate = { workspace = true, package = "mycrate_v2" }.

I think the workspace = { "mycrate_v2" } sounds neat but package would feel more straight forward imho (and based on the other related tickets it seems like its also the thing that people gravitate towards) (hope my 2 cents help here)

---

btw the obvious workaround for this is to just use the rename within your package (I assume that works)

file: member-2/Cargo.toml [dependencies] itoa-old.workspace = true

For people pressing this, the most relevant information would be why the workaround is not sufficient in your specific case.

this workaround would require us to use itoa-old instead of use itoa which was the goal (I assume)