Support quiet mode

[nashif]

Right now when flashing we get lots of output from both west and pyocd, for example:

west  flash --board-id OSHW000041114e45002a3006bcf000320571000097969900
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner pyocd
-- runners.pyocd: Flashing file: /Users/anashif/zephyr/zephyrproject/zephyr/build/zephyr/zephyr.hex
[====================] 100%
0001035:INFO:loader:Erased 0 bytes (0 sectors), programmed 0 bytes (0 pages), skipped 16384 bytes (4 pages) at 38.84 kB/s

When using west with sanitycheck in verbose mode, this is lots of output that disturbs the test progress reporting (might be relevant with sanitycheck -vv, but sanitycheck -v should not have this type of information).

Can we add support for -q (for quiet) with flash and probably with other commands please?

[mbolivar]

Thanks for filing an issue!

This should be feasible to do for the built-in commands as a starting point (west update -q, etc.), and then we can do the same thing in our zephyr extensions. Basically all west I/O goes through one module, which can learn lower verbosity levels than info by default, so it's just a matter of also capturing subprocess output and dealing with it appropriately.

It needs to be prioritized, though, so I'm going to leave this on the backlog for now.

[mbolivar]

@nashif how would you want this command to behave?

west -v update --quiet

options:

1. -v overrides --quiet
2. --quiet overrides -v
3. error

[sjg20]

I suggest that

west update

is silent, only showing warnings/errors. That is the way normal tools work, at least in linux.

Then west update -v

can spit out more stuff

and perhaps west update -d

can spit out loads of debug stuff also

[marc-hb]

That is the way normal tools work, at least in linux.

Most of the output of west update is not from west itself but from git. Which non-default git verbosity option(s) would you like west update to use by default?

I don't think "normal" tools that download something are completely silent by default; probably because most interactive users don't want to wait minutes-long timeouts to discover network or server issues and they also want to have an idea of how much longer this is going to take.

Note interactive use was not the main purpose of this bug. git is less verbose in non-interactive mode (see this with a simple git fetch 2>fetch.log). west update was not the main purpose of this bug either.

I think version control tools that download new versions are never silent by default, likely because most users want to know if there's new code (to rebase on, etc.)

Then west update -v can spit out more stuff and perhaps west update -d can spit out loads of debug stuff also

west help
-v, --verbose         Display verbose output. May be given multiple times
                        to increase verbosity.

[mbolivar-nordic]

@marc-hb basically took the words out of my mouth on this one.

[sjg20]

@mbolivar-nordic @marc-hb Perhaps you are talking about progress. This is what repo does:

$ repo sync -j30 -n

... A new version of repo (2.15) is available.
... You should upgrade soon:
cp /home/sjg/cosarm/.repo/repo/repo /home/sjg/cosarm/depot_tools/repo

Fetching: 40% (427/1054) aosp/platform/frameworks/native

If it showed the git output of 1k repos I would go mad!

[marc-hb]

It's great for repo to have an "aggregate" progress bar and this is actually being discussed in #508 where we came from. It's not silent though and again I'm not sure downloading is really relevant to this bug; it wasn't mentioned in the description and using the network tends to have different verbosity by default. So maybe move this particular topic to a new issue?

[sjg20]

Thanks @marc-hb I have said my piece :-)

[mbolivar-nordic]

I agree with @marc-hb that even repo is not "default quiet" given the example.

If it showed the git output of 1k repos I would go mad!

You must really strongly prefer ninja to make, then 😉 .

(I do actually have that preference, and your point about it probably being a good idea for west to make progress bars a little quieter -- though still not silent -- by default is well taken.)

I also agree that the assertion "well behaved command line tools should be silent on success by default" is historically true for Unix utilities. But it does not strike me as relevant to interactive tools like west, and it seems to me that other tools in the space (grepo, jiri, git itself) serve as counterexamples.

So while I'm sympathetic to avoiding spammy output, I think quiet by default for all west commands is not the right thing.

[sjg20]

@mbolivar-nordic I'll settle for less noisy. The quieter the tool, the quieter I will become.

I did not know that 'west update' is interactive, so perhaps that explains some of the console spam. I'd argue that git was written to be a little noisy partly because no one understood what it was doing. As it gets more mature perhaps it will quieten down?

Oh yes, I think ninja is quite broken as a build tool. Perhaps it came from the Windows world. I've even seen an issue where people are begging for separate stdout/stderr and getting rejected. Perhaps we should teach posix in schools.

[marc-hb]

I'd argue that git was written to be a little noisy partly because no one understood what it was doing.

Maybe but you're completely missing the different way downloading is always treated for the reasons listed above.

As it gets more mature perhaps it will quieten down?

I've observed the opposite: the UI seems to have more suggestions and even new commands like (use "git restore <file>..." to discard changes in working directory). The initial "elite" who used git saw the beautiful graph "through" the bad UI but now that it has become the unavoidable standard it must also hold the hand of users who don't care about version control and for whom some updates is a good enough commit message (real life example)

https://blog.ted.com/the-quotable-linus-torvalds-live-onstage-at-ted/

I can’t do UI to save my life. I mean if I was stranded on an island and the only way to get off that island was to make a pretty UI, I’d die there.

https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

[mgielda]

I think the most important thing would be to allow for a quiet option here (of course passing it to git). Changing the default is more controversial, and I think small steps are better than huge changes (since if we quieten west init/update down by default I am sure we will hear from many people who are not in this thread since they are not aware of the discussion, whereas if we just provide a new option, nobody will cry I suppose)

As for details: I would do quiet being mutually exclusive with verbose! And verbose is for me lower prio since those commands are already pretty verbose. So I would add a quiet (-q) flag, wait for people to request verbose, and if they do, probably discuss whether make it mutually exclusive but that would be my first intuition. But the relative importance of "give me a way to silence this super-long output" vs "give me EVEN MORE output" is for me 10:1.

[marc-hb]

While it is NOT exactly what was discussed in this issue, @pdgendt has just submitted a new -q option in:

• app: Add -q argument for quiet mode #723

[marc-hb]

Based on the description of (old) PR #598, removing west.log() seems to be pre-requisite:

Deprecate west.log (part of Global west state makes it harder to unit test #149 ) as prep work for parallelizing tests and adding west --quiet (#301 )

[marc-hb]

By all means please re-open this issue if @pdgendt 's brand new -q option (in west version 1.3) does not do what you requested. Or open a new, more focused issue: it looks like different topics were discussed above (and I don't have time to reproduce them all)