Support for workspaces

[malbarbo]

Consider adding support to use cargo watch in a workspace project.

You can see with cargo +nightly build --help the kind of options for workspace projects.

[passcod]

Can you explain what we'd need to watch for / execute in this context? At least for quick reference.

[malbarbo]

I think there are two strategies:

1. Watch rust files in every workspace member, when a file changes execute cargo passing the changed member to --package (-p). For example

cargo watch 'test' # execute 'cargo test -p mypackage' if a file changes in mypackage project

2. Require that the user specify the members to watch using --package (-p) or -all (similar to cargo build, test, etc), and forward the packages to cargo. For example

cargo watch -p mypackage 'bench' # watch mypackage files and execute `cargo bench -p mypackage`

[passcod]

Could probably do both, too. I'm not going to pick this up for the moment, but would merge a PR that implements it.

[colin-kiegel]

I think there are two aspects to workspace support:
(a) the set of crates being monitored
(b) the set of crates being tested / benched / etc.

What @malbarbo suggested are these two modes:

1. (a) monitor the full set of crates, but (b) only test the single crate that changed
2. (a) monitor a fixed set of crates, and (b) test exactly that same set of crates

Strategy (1) would be a good default since workspaces can be big.

On the other hand it is possible that changes have side effects on other crates within the same workspace. So it's definitely interesting to have a way to pass --all and monitor + test the full set of crates. This could be achieved with strategy (2).

.. however

I suggest to adopt this alternative strategy:

cargo watch could always watch the entire workspace. If the user passes a package flag (--package, -p or --all) it would still watch the entire workspace, but only test for side effects in the specified packages.

The difference is this:
Say we call cargo watch -p foo 'test' and then a crate bar is changed within the same workspace. Within this alternative suggestion foo would be recompiled/tested nevertheless, because it can be affected by that change. In @malbarbo s original suggestion the change to bar would be ignored.

[passcod]

With version 4.0.0, you can now run arbitrary commands and watch a lot more stuff by default. While that's not first-class support for workspaces yet, it's a step towards that. In addition, the -p, --all, and --package CLI flags/options are reserved (but hidden from help messages) for this usage.

[waynr]

I'd like to take a crack at implementing this if no one else is already working on it. @passcod got any suggestions for where to start?

[passcod]

Absolutely, thanks for offering!

I actually don't have any idea of what this would do! So I guess first step would be figuring out what the action would be. There's a bunch of stuff in the comments but I haven't really thought about this in, uh, two years.

I don't think this needs watchexec support, which simplifies things. There will need to be a flag added to the clap arguments, then whatever logic happens to translate/affect the arguments for watchexec. And that should be all!

[tzemanovic]

Personally, I find that the current version works well with a workspace project, where you can choose what package/action to run with the --exec argument.

I would however love to see support for [workspace] config when it's specified in Cargo.toml. That is to filter out packages from the exclude key list, similarly as is done for .gitignore.

[Nonius]

cargo watch in a workspace root changes the Cargo.lock file, which will trigger an infinite loop. Is this part of this issue?

[passcod]

I'd prefer that filed as a different issue (possible bug, not part of whatever feature this issue materialises as)

[Nonius]

I'd prefer that filed as a different issue (possible bug, not part of whatever feature this issue materialises as)

I've created #175