search

aspect-build / aspect-cli

correct, fast, usable: choose three
https://aspect.build/cli
Apache License 2.0
93 stars 21 forks source link

Support "watch mode" #63

Open alexeagle opened 3 years ago

alexeagle commented 3 years ago

We should add a plugin that does the same thing as bazel-watcher.

Give the user commands like

/cc @achew22

achew22 commented 3 years ago

To my naive eye I would like to keep test and watch-test (just to disambiguate) separate. I know a number of people who do not like the ibazel test behavior and I'd hate for them to not be able to use aspect because it doesn't comport with their workflow

alexeagle commented 3 years ago

there's bike-shedding to do for sure. I'd like to avoid hyphenated or modal commands if we can, these will be used so much.

aspect watch //one:target on a test target could be enough if that target is created by a *_test rule?

achew22 commented 3 years ago

That seems reasonable to me. I think the usecase of wanting to watch-build (again, I like this red bikeshed) is reasonably uncommon as to make it not worth optimizing. So, 3 modes of operation

  1. You've provided a query and it matches multiple targets, so ibazel build them (what about if you want to test them all?)
  2. You've provided a single target and it is a _binary, ibazel run it
  3. You've provided a single target and it's a _test, ibazel test it

Seems very reasonable to me. Only outstanding question is what if you want to test them all?

alexeagle commented 2 years ago

finally returning to this. I think for 1. we should ibazel test them all, if there are any test targets among the query results.

Nick-Mazuk commented 1 year ago

Another suggestion, we could just add the --watch flag to any of the aspect commands to watch it?

aspect build --watch //directory:target
aspect test --watch //directory:target
aspect run --watch //directory:target

This syntax would also allow users to easily compose the watch flag with custom commands.

aspect lint --watch //directory:target
alexeagle commented 1 year ago

Yes, that's a good point that custom commands might want to participate. Also the scheme above for deciding what bazel watch should mean would need to be communicated with users, and even if the scheme doesn't have flaws, longer documentation can be a clue that we did it wrong.

I think --watch as a flag can be a bit confusing - would you be allowed to put test --watch in your .bazelrc?

OTOH you could put a default for --watch in the BUILD file as a directive on some target (e.g. the devserver should always bazel run in watch mode).

Another concern is to avoid ever having collisions between our flags and Bazel's. We do have a precedent already for flags like --aspect:some_feature but I think watch mode should have a nice terse UI since there are some developers for whom they always run/test this way.

Overall I can totally be convinced to design it that way instead.

Nick-Mazuk commented 1 year ago

Those are all valid points.

Potentially another pattern is to make watch it's own command that can accept all other commands. I can't recall another CLI tool implementing this pattern (essentially "higher-order commands"), but it could be worth considering here.

aspect watch build //directory:target
aspect watch test //directory:target
aspect watch run //directory:target
alexeagle commented 2 weeks ago

I think "higher order commands" is hard to retrofit since Bazel tooling may assume how the command is structured, like an IDE plugin that lets user call Bazel, or a UI that reports the results of your build. I could imagine "watch" is the syntax sugar shorthand for one of "watch-build" or "watch-test" so there's a way to be explicit if the pattern resolves to something you don't expect