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

cargo fmt formats all crates in a workspace by default #2488

Closed
rtsuk opened this issue Feb 23, 2018 · 9 comments · Fixed by oli-obk/cargo_metadata#30
Closed

cargo fmt formats all crates in a workspace by default #2488

rtsuk opened this issue Feb 23, 2018 · 9 comments · Fixed by oli-obk/cargo_metadata#30

Comments

@rtsuk
Copy link

rtsuk commented Feb 23, 2018

I would much prefer it behave like cargo build, where it only operates on the crate in the current directory unless told otherwise.

@rtsuk
Copy link
Author

rtsuk commented Feb 23, 2018

I'd be happy to try to fix this one if folks agree with my preference.

@nrc
Copy link
Member

nrc commented Feb 24, 2018

Yeah, following cargo build seems like the correct behaviour here (though of course running in the root of the workspace should still format the whole workspace, just like cargo build does).

I'd be happy to try to fix this one if folks agree with my preference.

That would be awesome, thank you!

@matklad
Copy link
Member

matklad commented Feb 26, 2018

just like cargo build does

Note that cargo build behavior is actually pretty nuanced these days. The flags which affect which crates are built are --package , --all and --exclude. Additionally, default_members attribute of a virtual root Cargo.toml manifests affects behavior in the root of the workspace. And, if the root of the workspace is not virtual, than only the root is built, and not the whole workspace.

So, yeah, basically most custom subcommands should accept --all, --exclude and --package flags, and behave like build-in commands, but there's no easy way to achieve that behavior in custom sub commands, except by replicating parts of Cargo :-(

@rtsuk
Copy link
Author

rtsuk commented Feb 26, 2018

Should I move this issue over to rustfmt-bin?

@nrc
Copy link
Member

nrc commented Mar 1, 2018

Should I move this issue over to rustfmt-bin?

No, I'm not sure what the future will be like for rustfmt-bin, so we'll continue tracking issues here for a while.

@cramertj
Copy link
Member

This issue was fixed by #2513

@topecongiro
Copy link
Contributor

Closed via #2513.

@eoger
Copy link

eoger commented Apr 14, 2020

This was re-reverted later by #3652, can be re-open this?

@calebcartwright
Copy link
Member

@eoger would you open a new issue with your corresponding rustfmt version and other relevant details? At least with rustfmt 1.4.13 cargo fmt is operating as described/requested in this issue.

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 a pull request may close this issue.

7 participants