Skip to content

Configuration specific dependencies break cargo tree #13854

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

Closed
abrisco opened this issue May 3, 2024 · 6 comments
Closed

Configuration specific dependencies break cargo tree #13854

abrisco opened this issue May 3, 2024 · 6 comments
Labels
C-bug Category: bug S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.

Comments

@abrisco
Copy link

abrisco commented May 3, 2024

Problem

Running cargo tree on the following yaml now fails in Nightly releases of Cargo

[package]
name = "target_cfg_features"
version = "0.1.0"
edition = "2018"

# Required to satisfy cargo but no `lib.rs` is expected to
# exist within test data.
[lib]
path = "lib.rs"

[dependencies]
tokio = "1.25.0"

[target.'cfg(unix)'.dependencies.tokio]
features = ["fs"]

Stable

target_cfg_features v0.1.0 (/target_cfg_features)
└── tokio v1.25.0
    └── pin-project-lite v0.2.9
    [build-dependencies]
    └── autocfg v1.1.0

Nightly

error: failed to parse manifest at `/target_cfg_features/Cargo.toml`

Caused by:
  dependency (tokio) specified without providing a local path, Git repository, version, or workspace dependency to use

Steps

Use Cargo.toml from above and run cargo tree

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.78.0 (54d8815d0 2024-03-26)
cargo 1.80.0-nightly (6087566b3 2024-04-30)
@abrisco abrisco added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels May 3, 2024
@weihanglo
Copy link
Member

It was a bug we fixed recently in #13775. The bug has been there for a long while. Now Cargo disallows dependencies without any source, to avoid confusion.

dependency (tokio) specified without providing a local path, Git repository, version, or workspace dependency to use

To fix this, follow the instruction and specify a version, or any other kind of dependency. Like

[target.'cfg(unix)'.dependencies.tokio]
features = ["fs"]
version = "1.25.0"

@weihanglo weihanglo added S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. and removed S-triage Status: This issue is waiting on initial triage. labels May 3, 2024
@abrisco
Copy link
Author

abrisco commented May 3, 2024

Is there a way to refer to the same version defined in [dependencies] directly?

@abrisco
Copy link
Author

abrisco commented May 3, 2024

And what was the behavior before? It certainly seems like the behavior was to inherit the version from [dependencies]. It seems like the intent of #13775 was to fix

[dependencies]
tokio = {}

not prohibit the example in the original post. I think I lack some context to comprehend everything in the original post though.

@weihanglo
Copy link
Member

Is there a way to refer to the same version defined in [dependencies] directly?

If you have a Cargo workspace, [workspace.dependencies] is made for that.

It certainly seems like the behavior was to inherit the version from [dependencies]

No it was not. If you remove the entire [dependencies] table from you example, and build with older Cargo, you will get the latest tokio as well. It was a bug that wrongly set version = "*" for every dependency that has no source kind. To prove it, run this command in you example project and check if the version req of tokio is *.

cargo metadata | jq '.packages[] | select(.name=="target_cfg_features")'

@abrisco
Copy link
Author

abrisco commented May 3, 2024

Is there a way to refer to the same version defined in [dependencies] directly?

If you have a Cargo workspace, [workspace.dependencies] is made for that.

It certainly seems like the behavior was to inherit the version from [dependencies]

No it was not. If you remove the entire [dependencies] table from you example, and build with older Cargo, you will get the latest tokio as well. It was a bug that wrongly set version = "*" for every dependency that has no source kind. To prove it, run this command in you example project and check if the version req of tokio is *.

cargo metadata | jq '.packages[] | select(.name=="target_cfg_features")'

Does the current stable behavior (intended of otherwise) conform the target.cfg dependency to the version defined in [dependencies]? I definitely agree the case where [dependencies] is omitted and there's no version info in the target.cfg entry should fail. But certainly feels like this "fix" (which again I partially agree and am thankful for, thank you!) has taken away desired behavior.

My expectations are

  1. All [dependencies] entries must have version info
  2. Any unversioned target.cfg entries will inherit versions from [dependencies]
  3. target.cfg entries are free to specify independent version info
  4. target.cfg entries that do not match anything in [dependencies] should error if no version info is provided.

That being said, I lack the bandwidth to drive any of these changes so mostly wanted to share feedback and have some questions answered. I'll close this out for now until there's more engagement from other users.

Thank you for your time!

@abrisco abrisco closed this as completed May 3, 2024
@weihanglo
Copy link
Member

Does the current stable behavior (intended of otherwise) conform the target.cfg dependency to the version defined in [dependencies]

No. It was just a coincidence. The dependency resolver saw both syn = "1" from dependencies, and syn = "*" from target-specific dependencies. From the definition of * version requirement, it matches anything on that position.

I would say it was a bug (or misfeature if you like) that may lead to more dependency-confusions (in the sense of people being confused, not exactly dependency confusion attack), so I lean toward not supporting implicit dependency inheritance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.
Projects
None yet
Development

No branches or pull requests

2 participants