-
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
Don't require dev-dependencies when not needed in certain cases #5012
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
cargo build --help says: --all-targets Build all targets (lib and bin targets by default) but the old default behaviour was actually doing --all-targets. This meant that --avoid-dev-deps was only effectively if one gave --lib --bins explicitly. With this commit, `cargo build --avoid-dev-deps` with no other flags, will build lib and bins and avoid installing dev-dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Would it also be possible to include tests as well for this new functionality?
src/bin/build.rs
Outdated
@@ -63,6 +64,7 @@ Options: | |||
--features FEATURES Space-separated list of features to also build | |||
--all-features Build all available features | |||
--no-default-features Do not build the `default` feature | |||
--avoid-dev-deps Avoid installing dev-dependencies if possible |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this start out as a -Z
flag to be unstable by default?
src/cargo/ops/cargo_compile.rs
Outdated
TargetKind::Bin => true, | ||
TargetKind::Lib(..) => true, | ||
_ => false, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come this needed changing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not necessary and could be dropped from this PR. But without it, the current situation means I have to give extra flags to cargo build
, it contradicts the documentation, and it also means the all-targets
flag is redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm sorry I missed this earlier, but I'm not sure I quite understand this. Could this perhaps be left out for a future PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(or maybe a test could be added?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually opened up a whole new can of worms, so I've reverted it from this PR and opened up a new issue #5134 which I'll file a PR for as soon as this PR is merged (I have a fix, but it builds on top of this PR).
@@ -175,7 +175,11 @@ fn install_one(root: &Filesystem, | |||
|
|||
let ws = match overidden_target_dir { | |||
Some(dir) => Workspace::ephemeral(pkg, config, Some(dir), false)?, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the optional deps flag be set for this as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ephemeral() already sets that internally
&specs)?; | ||
let features = Method::split_features(features); | ||
let method = Method::Required { | ||
dev_deps: ws.require_optional_deps() || filter.need_dev_deps(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the name optional_deps
could change since it's affecting dev-dependencies?
Additionally, I think that we'd want this flag to affect target-specific dependencies, right? If this is a sort of "one shot" compilation there should also be no need to resolve and require windows-specific dependencies when on Linux, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind if we leave that as a TODO for the future? What you say makes sense but it is not actually needed in Debian right now, because we union over all targets when translating dependencies - so e.g. winapi etc are all pulled in regardless of what target you're building for. This means we have to have less special-cases in the packaging, and also supports cross-compilation later.
If I understood correctly, on Fedora they are patching out windows dependencies so they don't appear in Cargo.toml, so this functionality wouldn't be needed either. (Perhaps @ignatenkobrain can confirm).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok sure yeah, I think a TODO should suffice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unsure if it's appropriate to mention "targets" in the sense of "platform" here on this line. The term "target" in the context of CompileFilter and core::Target
and cargo build
options, seems rather to mean "lib/bin/examples/tests" etc and not platform.
OTOH the functionality you mention does seem to be missing - if I add [target."XXXX".dependencies] YYY = "999"
to Cargo.toml then cargo install
still fails with this PR, despite the fact that "XXXX" does not match the current platform. I'm just unsure of the appropriate place to add this TODO, please advise. Perhaps on struct Method
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm ok, perhaps an issue can be filed? I think the -Z avoid-dev-deps
flag added here may in the long run want to be something like --minimal-cargo-lock
which prunes all non-relevant dependencies like platform-specific dependencies that don't apply, dev-deps if you're not building tests, etc. In that sense I think the feature/TODO here is slightly broader than a comment in the code. Would you be ok filing that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed as #5133
Thanks for the comments, I'll soon find some time to write tests and switch to |
Hey, I've added some tests and changed I wasn't quite sure what to rename |
☔ The latest upstream changes (presumably #5063) made this pull request unmergeable. Please resolve the merge conflicts. |
Thanks for the update, tests look good to me! It's also ok to not worry much about naming, despite being public we bump the major version for Cargo regularly so it's not too critical to think too hard about APIs |
I've resolved the merge conflict and dealt with all the remaining issues I think, please take a look and merge if good. |
Ah looks like some tests may be failing? |
Turns out the tests were also dependent on the fix for #5134, I've pushed a commit to work around it. Should be all good now. |
@bors: r+ |
📌 Commit d46db71 has been approved by |
Don't require dev-dependencies when not needed in certain cases Specifically, when running `cargo install` and add a flag for this behaviour in `cargo build`. This closes #4988.
☀️ Test successful - status-appveyor, status-travis |
Stricter need_dev_deps behaviour The previous PR (#5012) contained an unnecessary work-around for behaviour of `--all-targets` that was misunderstood. This PR removes that work-around and adds some tests and comments to clarify the behaviour for future contributors, which may help to make easier a future fix for #5177 and #5178.
Applied-Upstream: rust-lang/cargo#5012 Applied-Upstream: rust-lang/cargo#5186 Gbp-Pq: Name 1001_PR5012.patch
This fixes an accidental regression introduced in rust-lang#5012 where the `--all-features` CLI flag was only propagated to the "main crate" as opposed to all workspace packages. This behavior has [already been deemed][pr] as "basically not what you want", but for now it's best to avoid the regression. Closes rust-lang#5518 [pr]: rust-lang#5353
Copy `--all-features` request to all workspace members This fixes an accidental regression introduced in #5012 where the `--all-features` CLI flag was only propagated to the "main crate" as opposed to all workspace packages. This behavior has [already been deemed][pr] as "basically not what you want", but for now it's best to avoid the regression. Closes #5518 [pr]: #5353
This fixes an accidental regression introduced in rust-lang#5012 where the `--all-features` CLI flag was only propagated to the "main crate" as opposed to all workspace packages. This behavior has [already been deemed][pr] as "basically not what you want", but for now it's best to avoid the regression. Closes rust-lang#5518 [pr]: rust-lang#5353
Applied-Upstream: rust-lang/cargo#5012 Applied-Upstream: rust-lang/cargo#5186 Gbp-Pq: Name 1001_PR5012.patch
Applied-Upstream: rust-lang/cargo#5012 Applied-Upstream: rust-lang/cargo#5186 Gbp-Pq: Name 1001_PR5012.patch
Specifically, when running
cargo install
and add a flag for this behaviour incargo build
.This closes #4988.