Provide a way to run cargo subcommands on all crates in the workspace

[euclio]

This is mentioned as a "future extension" in RFC 1525.

[alexcrichton]

Thanks for the issue @euclio! This was indeed intended to have an issue. And to expand a bit the thought was to add --all flags to many subcommands so executions like:

cargo test --all

would test all the crates in a workspace, or

cargo publish --all

would publish all crates in a workspace that haven't already been published.

[DrRibosome]

just wondering if anyone is still working on this

[alexcrichton]

@jdc2172 I don't believe the currently is, but if you'd like to take it feel free!

[retep998]

cargo doc --all would be exceptionally useful.

[euclio]

I'd be interested in tackling this, but I think we need to hammer out which commands should get this flag.

Also, what sort of implementation approach should be taken?

[steveklabnik]

cargo build and cargo test are the biggies for me.

[DrRibosome]

Cargo test definitely needs this.

Not sure cargo build is as high priority given that it already builds path
deps in the crate

On Fri, Sep 30, 2016, 6:32 PM Steve Klabnik notifications@github.com
wrote:

cargo build and cargo test are the biggies for me.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2878 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHmfeh16DgMThxKntuIleFSaX_eVtI-ks5qvY34gaJpZM4JMpzT
.

[steveklabnik]

Oh yeah. That's what I get for hasty commenting! On my project that uses workspaces, those are the only two sub commands I use, so I didn't think it through 😅😞

On Sep 30, 2016, 18:57 -0400, Jack Crawford notifications@github.com, wrote:

Cargo test definitely needs this.

Not sure cargo build is as high priority given that it already builds path
deps in the crate

On Fri, Sep 30, 2016, 6:32 PM Steve Klabnik notifications@github.com
wrote:

cargo build and cargo test are the biggies for me.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2878 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHmfeh16DgMThxKntuIleFSaX_eVtI-ks5qvY34gaJpZM4JMpzT
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (#2878 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AABsijei0_YDV9nu6hCIS8o69VRvBBEFks5qvZPkgaJpZM4JMpzT).

[alexcrichton]

@euclio to me yeah test and doc are the biggies to cover here. I think publish would also be great but that has other tricky semantics we'd want to cover later.

[euclio]

@alexcrichton Trying to get my feet wet with test. What's the best plan of attack here? Modifying ops::compile to take a flag to compile all members of the workspace instead of the current?

[alexcrichton]

@euclio yeah there's a few points where the -p flag is passed down, but that could just be an enum of either a -p flag or a --all flag. When that needs to be resolved we can then just iterate over all packages in a workspace.

[euclio]

@alexcrichton How should I handle the ambiguity when the member has the same name as a dependency?

[alexcrichton]

Oh that's ok, -p is a "package id specification" which will uniquely identify a crate in the dependency graph