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

Add --exclude flag #4031

Merged
merged 5 commits into from
May 28, 2017
Merged

Add --exclude flag #4031

merged 5 commits into from
May 28, 2017

Conversation

torkleyy
Copy link
Contributor

Allows to exclude packages in conjunction
with --all.

Addresses #2878

@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 @brson (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.

Copy link
Contributor Author

@torkleyy torkleyy left a comment

Choose a reason for hiding this comment

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

First contribution, would really appreciate if somebody could answer my questions.

src/bin/build.rs Outdated
let spec = match (options.flag_all, &options.flag_exclude) {
(true, exclude) if exclude.is_empty() => Packages::All,
(true, exclude) => Packages::OptOut(exclude),
(false, exclude) if !exclude.is_empty() => panic!("--exclude can only be used together \
Copy link
Contributor Author

@torkleyy torkleyy May 11, 2017

Choose a reason for hiding this comment

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

How would I return a proper error here? More specifically, should I build the CargoError myself or is there some convenience function? Can I use the bail! macro from there?

Copy link
Member

Choose a reason for hiding this comment

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

Yep, bail! is for this use case:

let cfg = match color {
Some("auto") => Auto,
Some("always") => Always,
Some("never") => Never,
None => Auto,
Some(arg) => bail!("argument for --color must be auto, always, or \
never, but found `{}`", arg),
};

src/bin/build.rs Outdated
Packages::All
} else {
Packages::Packages(&options.flag_package)
let spec = match (options.flag_all, &options.flag_exclude) {
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 match would be used in many subcommands. May I place it in cargo::util?

Copy link
Member

Choose a reason for hiding this comment

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

You could add Packages::from_flags(flag_all, flag_exclude) -> CargoResult<Packeges>.

@@ -43,6 +44,7 @@ Options:
-h, --help Print this message
-p SPEC, --package SPEC ... Package to build
--all Build all packages in the workspace
--exclude SPEC ... Exclude packages from the build
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 seems pretty verbose to manually handle conflicts / requirements of flags. Is there a way to let docopt do this? There is currently sort of a bug when executing cargo build -p whatever --all: The -p is silently ignored.

Copy link
Member

Choose a reason for hiding this comment

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

Is there a way to let docopt do this?

Basically we need to switch to clap, and hopefully get rid of a lot of duplication along the way. But this is a hard task :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Basically we need to switch to clap

Oh it is desired to switch to clap? It's good to hear that! Is there someone working on it already? If not, I'd love to do it.

Copy link
Member

Choose a reason for hiding this comment

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

Is there someone working on it already?

I've tried to do that, but haven't arrived at something very satisfying :)

It would be super if you would be able to pull this off!

@torkleyy torkleyy force-pushed the exclude branch 3 times, most recently from fb72d95 to 82cc47e Compare May 12, 2017 14:52
@torkleyy torkleyy changed the title [WIP] Add --exclude flag Add --exclude flag May 12, 2017
@torkleyy
Copy link
Contributor Author

I'd say this is ready for review.

@matklad
Copy link
Member

matklad commented May 15, 2017

@alexcrichton what do you think about it? I feel that we definitely need something like this, but I am worried that we will have three flags (-pkg, -all, -exclude) to control this behavior.

Hm, maybe we want --pkg foo, --pkg -foo, --pkg *?

@torkleyy
Copy link
Contributor Author

@matklad is "-foo" allowed as argument? If that's the case, I agree that it makes more sense to only have one flag for all of them. Just used --exclude because it was mentionend in that issue.

@alexcrichton
Copy link
Member

Thanks for the PR @torkleyy! This seems fine to me, @matklad we've got enough flags at this point for "target selection" that it may make sense to basically house their documentation elsewhere at some point. Do you think canonicalizing in one --pkg argument with some syntax is better though? I feel like apart from docs --exclude at least is more self-explanatory than --pkg -foo.

@bors
Copy link
Contributor

bors commented May 16, 2017

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

@torkleyy
Copy link
Contributor Author

Rebased

@matklad
Copy link
Member

matklad commented May 16, 2017

I feel like apart from docs --exclude at least is more self-explanatory than --pkg -foo.

Yeah, --exclude is good enough. It's not obvious though what exactly are you excluding:

cargo test --all --exclude baz

Are we excluding baz package or baz module here?

Another option for flag name is --exclude--pkg.

@torkleyy
Copy link
Contributor Author

@matklad I feel excluding a module would be a cheat somehow, so I wouldn't expect it to be possible with cargo. Also you can easily read the description of --exclude. We shouldn't make the flag longer than necessary.

@torkleyy
Copy link
Contributor Author

torkleyy commented May 16, 2017

It seems we got platform-specific behavior here:

I implemented a test which checks for this pattern:

"[..] Compiling bar v0.1.0 ([..])\n\
[..] Compiling foo v0.1.0 ([..])\n

It matches on Linux, however on Windows it seems to compile the crates the other way around.

EDIT: Now it even fails locally, so apparently behavior has changed. Fixing..
Huh? It fails both ways now... What's going on?

@matklad
Copy link
Member

matklad commented May 16, 2017

Huh? It fails both ways now... What's going on?

I bet foo and bar just compile in parallel in arbitrary order. You can use with_stderr_contains and with_stderr_does_not_contain (or you can put broken code in the excluded package and check that it does not break compilation).

Hm, what would happen if you compile foo and exclude bar if foo depends on bar? Should we add this test case?

@torkleyy
Copy link
Contributor Author

exclude bar if foo depends on bar? Should we add this test case?

Oops, thought about this, but completely forgot it!

I'm not sure actually. I think the current behavior is just compiling it if it's a dependency.

@matklad
Copy link
Member

matklad commented May 25, 2017

Let's assign @alexcrichton to this :)

r? @alexcrichton

@rust-highfive rust-highfive assigned alexcrichton and unassigned brson May 25, 2017
@alexcrichton alexcrichton added the relnotes Release-note worthy label May 26, 2017
@alexcrichton
Copy link
Member

@bors: r+

Looks great to me, thanks again for the PR @torkleyy!

@bors
Copy link
Contributor

bors commented May 26, 2017

📌 Commit 9ad240b has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented May 26, 2017

⌛ Testing commit 9ad240b with merge 50791b8...

@bors
Copy link
Contributor

bors commented May 26, 2017

💔 Test failed - status-travis

@torkleyy
Copy link
Contributor Author

Fixed (it failed because it expected a "filtered out" argument).

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented May 26, 2017

📌 Commit b356af0 has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented May 26, 2017

⌛ Testing commit b356af0 with merge 9b856c7...

@bors
Copy link
Contributor

bors commented May 26, 2017

💔 Test failed - status-travis

@torkleyy
Copy link
Contributor Author

Huh? It works for me, even after rebasing onto upstream/master. Anyways, I'll push a fix any moment...

by using with_stderr_contains because
parallel build may mix up the lines.

Additionally, remove the last line of
the benchmark.
@alexcrichton
Copy link
Member

@bors: r+

Ah yeah I think that's a very recent change on nightly

@bors
Copy link
Contributor

bors commented May 27, 2017

📌 Commit dee3c2e has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented May 27, 2017

⌛ Testing commit dee3c2e with merge 015897a...

bors added a commit that referenced this pull request May 27, 2017
Add --exclude flag

Allows to exclude packages in conjunction
with --all.

Addresses #2878
@bors
Copy link
Contributor

bors commented May 28, 2017

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

@bors bors merged commit dee3c2e into rust-lang:master May 28, 2017
@torkleyy torkleyy deleted the exclude branch May 28, 2017 03:10
bors added a commit that referenced this pull request Feb 26, 2018
…hton

Support --exclude option for `cargo doc`

I think this should have been implemented when the feature was added for
other commands. Probably just an oversight.

cc #4031

r? @alexcrichton
@ehuss ehuss added this to the 1.19.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Release-note worthy
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants