-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Support the [features]
section in virtual manifests
#4942
Comments
Thanks for the report! Unfortunately though the |
@alexcrichton any hope in future about this improvement ? |
@twistezo I'll tag it as a feature request. |
I have a different issue, that fits under this as an ‘umbrella issue’. Given these conditions:
Then this fails: cargo run --package crate --bin other_executable --features other_executable_feature
Whereas this succeeds: cargo run --package crate --bin other_executable --all-features As well as this: cd "${virtual_workspace_directory:?}" &&
cargo run --package crate --bin other_executable --features other_executable_feature |
Any updates on this? |
@Michel-Haber it's unclear what semantics exactly As for " |
@matklad It seems reasonable to me for a workspace to be able to specify its features as re-exports of package features. i.e: [features] A logical link may or may not exist between feature1 and feature2, but this allows for a cleaner selection of features for a set of projects, and, in its simplest form, would simply be a re-export of a package's feature. This also fixes the unexpected behaviour of --features flag, since it becomes tied to the workspace itself, and not its packages. |
This tripped me up and cased me a couple of hours of confusion. Cargo does not seem to pass on features to subcrates in a virtual workspace, nor does it respond to something you’d expect, like `cargo test -features=“moniker/codespan”`. This meant that I actually comitted buggy code to the repository! I’m working around this for now using `--manifest-path` method - it’s pretty gross though. There is an issue at rust-lang/cargo#4942 recording other people’s experiences with this behaviour.
This tripped me up and caused me a couple of hours of confusion. Cargo does not seem to pass on features to subcrates in a virtual workspace, nor does it respond to something you’d expect, like `cargo test -features=“moniker/codespan”`. This meant that I actually comitted buggy code to the repository! I’m working around this for now using `--manifest-path` method - it’s pretty gross though. There is an issue at rust-lang/cargo#4942 recording other people’s experiences with this behaviour.
This tripped me up and caused me a couple of hours of confusion. Cargo does not seem to pass on features to subcrates in a virtual workspace, nor does it respond to something you’d expect, like `cargo test -features=“moniker/codespan”`. This meant that I actually comitted buggy code to the repository! I’m working around this for now using `--manifest-path` method - it’s pretty gross though. There is an issue at rust-lang/cargo#4942 recording other people’s experiences with this behaviour.
This meant I wasted a bit of time today, so I linked the PR above. I just went with the |
Please add a warning, so other poeple know about this, that would've saved me a couple of hours. |
I also encountered this as part of brendanzab/codespan#31. At a glance, it seems like @Michel-Haber's solution of having top-level feature flags which can enable specific crate features seems to be the most intuitive. What would be required to get the ball rolling on this? |
There's some more information about this in #5849, notably how we tried to fix this but ended up being unable to because it's technically a breaking change. |
Is it possible to allow us to 'opt in' to this, by allowing us to explicitly forward features in virtual manifests? [workspace]
members = [
"./codespan",
"./codespan-reporting",
"./codespan-lsp",
]
[features]
"codespan/memory_usage" = ["codespan/memory_usage"]
"codespan-reporting/memory_usage" = ["codespan-reporting/memory_usage"] It's not pretty, but it would at least clean up the icky workarounds we have to do when working with workspaced crates, and also allow us to set these features in the RLS config (which is not currently possible). I don't know if this would make future fixes more difficult though. Would also be super nice to provide a warning when trying to use features without this explicit forwarding as well. |
@alexcrichton One way of following the solution of top-level feature flags without introducing breaking change would be to actually ignore the feature flags if a features section is not present in the workspace toml file. If one is present but not well defined or used, this is a syntax error. I rewrote @brendanzab 's proposition to show a more general approach to this: [workspace] [features] This can be used with: But seeing as silently ignoring feature flags cannot be reasonably considered a feature but rather a bug, one can argue that any breakage, like the one caused by #5390 is in fact due to a bug fix! |
Oh yes indeed! The previous fix may have been too big a hammer and I'd definitely believe it's possible to solve this without breaking crates. I don't personally (nor do I think @matklad) has time to work on this right now, but we can certainly help review PRs to finish implementing this! |
@sanmai-NL I think your issue (and mine) are distinct from this, as it does not include a |
[features]
section in virtual manifests
I slightly object to adding
If there is anything that only a |
Based on the above, I actually propose to the cargo team that we close this. |
Go ahead and close this. Please let us know if there is something wrong. |
I have project structure:
Main manifest
./Cargo.toml
:Workspace manifest
./workspace_a/Cargo.toml
:And
./workspace_a/lib.rs
:When i'm in root and trying
cargo test --all --features only_a
virtual manifest doesn't see feature in my workspace.It's working when i'm in
./workspace_a/
or when main manifest it's not virtual.The text was updated successfully, but these errors were encountered: