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

Inconsistent behavior when adding dependency tracked in workspace to member #14574

Closed
msmoiz opened this issue Sep 20, 2024 · 1 comment
Closed
Labels
C-bug Category: bug Command-add S-triage Status: This issue is waiting on initial triage.

Comments

@msmoiz
Copy link

msmoiz commented Sep 20, 2024

Problem

When I declare a dependency that includes an underscore (_) in its name under [workspace.dependencies] in the manifest of my virtual workspace and then add that dependency to a member crate using cargo add, I get different results depending on how I invoke the command:

  1. If I specify the dependency with an underscore, it is added to the member manifest as <dependency>.workspace = true
  2. If I specify the dependency with a hyphen, it is translated but then added to the member manifest as <dependency> = "version"

Expected behavior: Since the dependencies are the same in both cases, I would expect both invocations to result in <dependency>.workspace = true.

Steps

Folder structure

|-- Cargo.toml
|-- crate/
|---- Cargo.toml

Cargo.toml (workspace)

[workspace]
members = ["crate"]
resolver = "2"

[workspace.dependencies]
env_logger = "0.11.5"

Cargo.toml (crate)

[package]
name = "foo"
version = "0.1.0"
edition = "2021"

[dependencies]
env_logger.workspace = true # cargo add env_logger
env_logger = "0.11.5" # cargo add env-logger

Possible Solution(s)

It seems like Cargo compares the desired dependency to the dependencies listed in the workspace manifest at some point, to decide when to use <dependency>.workspace = true. It also seems like Cargo translates hyphens to underscores when appropriate. But perhaps the comparison happens before the translation, so we see this behavior (just my guess). If we reverse the order of those operations, then that should solve the issue.

Notes

No response

Version

cargo 1.76.0 (c84b367 2024-01-18)
release: 1.76.0
commit-hash: c84b367
commit-date: 2024-01-18
host: x86_64-apple-darwin
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.7.1 (sys:0.4.70+curl-8.5.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w 11 Sep 2023
os: Mac OS 14.6.1 [64-bit]

@msmoiz msmoiz added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Sep 20, 2024
@weihanglo
Copy link
Member

It looks like a dup of #13702 and has already been fixed by #13765. The fix is available in latest nightly and targeted at 1.83 release. Close as resolved. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug Command-add S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants