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

Don't require dev-dependencies when not needed in certain cases #5012

Merged
merged 9 commits into from
Mar 7, 2018

Conversation

infinity0
Copy link
Contributor

Specifically, when running cargo install and add a flag for this behaviour in cargo build.

This closes #4988.

@rust-highfive
Copy link

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.
Copy link
Member

@alexcrichton alexcrichton left a 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
Copy link
Member

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?

TargetKind::Bin => true,
TargetKind::Lib(..) => true,
_ => false,
},
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Member

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?)

Copy link
Contributor Author

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)?,
Copy link
Member

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?

Copy link
Contributor Author

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(),
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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!

Copy link
Contributor Author

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?

Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed as #5133

@infinity0
Copy link
Contributor Author

Thanks for the comments, I'll soon find some time to write tests and switch to -Z for the new flag.

@infinity0
Copy link
Contributor Author

Hey, I've added some tests and changed avoid-dev-deps to be a -Z unstable flag.

I wasn't quite sure what to rename require_optional_deps to, and it's a public struct so switching would carry some extra cost. I did add a comment to it, describing the new behaviour. I could change it if you want though, like require_extra_deps or require_unneeded_deps, let me know which you prefer.

@bors
Copy link
Collaborator

bors commented Feb 21, 2018

☔ The latest upstream changes (presumably #5063) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Copy link
Member

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

@infinity0
Copy link
Contributor Author

I've resolved the merge conflict and dealt with all the remaining issues I think, please take a look and merge if good.

@alexcrichton
Copy link
Member

Ah looks like some tests may be failing?

@infinity0
Copy link
Contributor Author

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.

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Collaborator

bors commented Mar 7, 2018

📌 Commit d46db71 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Mar 7, 2018

⌛ Testing commit d46db71 with merge 879f483...

bors added a commit that referenced this pull request Mar 7, 2018
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.
@bors
Copy link
Collaborator

bors commented Mar 7, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 879f483 to master...

@bors bors merged commit d46db71 into rust-lang:master Mar 7, 2018
bors added a commit that referenced this pull request Mar 21, 2018
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.
raspbian-autopush pushed a commit to raspbian-packages/cargo that referenced this pull request Mar 28, 2018
Applied-Upstream: rust-lang/cargo#5012
Applied-Upstream: rust-lang/cargo#5186

Gbp-Pq: Name 1001_PR5012.patch
alexcrichton added a commit to alexcrichton/cargo that referenced this pull request May 21, 2018
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
bors added a commit that referenced this pull request May 24, 2018
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
alexcrichton added a commit to alexcrichton/cargo that referenced this pull request May 24, 2018
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
raspbian-autopush pushed a commit to raspbian-packages/cargo that referenced this pull request Jun 20, 2018
Applied-Upstream: rust-lang/cargo#5012
Applied-Upstream: rust-lang/cargo#5186

Gbp-Pq: Name 1001_PR5012.patch
raspbian-autopush pushed a commit to raspbian-packages/cargo that referenced this pull request Jun 20, 2018
Applied-Upstream: rust-lang/cargo#5012
Applied-Upstream: rust-lang/cargo#5186

Gbp-Pq: Name 1001_PR5012.patch
@ehuss ehuss added this to the 1.26.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

cargo shouldn't check for dev-dependencies when running cargo build or cargo install
5 participants