[aloucks]

I sometimes find myself wanting to clean out a project without blowing away the dependencies. The -p option works, but can be tedious, especially in a multi-crate workspace.

This PR add a --no-deps option to preserve all non-workspace artifacts. The flag name and docs are modeled after cargo doc --no-deps.

Inspired by: #573 (comment)

[rust-highfive]

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.

[alexcrichton]

Thanks for the PR and sorry for the delay! This seems like a reasonable feature to me, but I think it should mirror the behavior of cargo doc --no-deps. The behavior there is sort of "document the specified packages but not their dependencies", but it means "don't clean workspace members" here. The commands are already somewhat different in that cargo doc doesn't mean "document everything" in the same way cargo clean means "remove everything", though.

Overall I'm not really sure how this would fit in well with the CLI. We've historically wanted to avoid too many flags being added to too many commands for niche purposes. Perhaps the best way to interpret this would be for cargo clean --no-deps to only clean the current package, which more closely aligns with cargo clean a bit.

[ehuss]

I'd like to better understand the use case here. Why is this useful?

[aloucks]

The behavior there is sort of "document the specified packages but not their dependencies", but it means "don't clean workspace members" here.

It's the opposite. cargo clean --no-deps would mean clean workspace memebers but not dependencies.

I'd like to better understand the use case here. Why is this useful?

cargo build doesn't generate compile warnings again until the workspace is cleaned or a file is modified. If I want to check multiple crates, i'd have to modify at least one file per crate in the workspace.

[ehuss]

cargo build doesn't generate compile warnings again until the workspace is cleaned or a file is modified. If I want to check multiple crates, i'd have to modify at least one file per crate in the workspace.

I would prefer to fix that instead of adding new flags. There is a fix on nightly via -Z cache-messages for that specifically.

[alexcrichton]

I agree with @ehuss that if the sole motivation for this is to get warnings then I'd say we should wait to stabilize -Z cache-messages behavior as the default.

[aloucks]

I don't know if I'd want the default behavior to change. I'd just like a way to opt-in to getting any and all warnings again. The metadata + jq trick works, but having support in cargo makes it easier and cleaner. This change is really just a way to automate the -p option for all workspace packages.

Warning messages aren't the only motivation though. Most of the time that I want to run cargo clean I actually want cargo clean --no-deps. I want to clean my project, but preserve the dependencies so my next cargo build is significantly faster.

[alexcrichton]

I think I would personally prefer to lean on waiting for -Z cache-messages to come along and re-evaluate what's needed here. This seems like a pretty niche feature if that exists which although it's perhaps useful in some circumstances is perhaps not worth the weight it would carry in Cargo.

[bors]

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

[lopopolo]

@ehuss @alexcrichton It is simpler to clean a sys crate than it is to configure a build.rs to force a rebuild when any C source changes. A sys crate is often a dependency of other crates in a workspace, so it is desirable to do a clean build of just the crates in the workspace.

[alexcrichton]

Ok so caching of messages has been stabilized and the original motivation here I believe is largely fixed. I'm gonna go ahead and close this because we're unlikely to take this, but if there's other more targeted use cases we'd appreciate issues for them!