Hi, Simon Tournier <zimon.touto...@gmail.com> writes:
> Hi, > > On Tue, 26 Sep 2023 at 12:19, Maxim Cournoyer <maxim.courno...@gmail.com> > wrote: > >>> Where should the user of the Guix command-line interface be expected >>> to read about the verbosity LEVEL argument that they can pass to >>> `--verbosity` and that is also valid? > > To answer a question elsewhere in this threads, I think these levels > come from Nix and daemon side. > >> See info '(guix) Invoking guix build': >> >> --8<---------------cut here---------------start------------->8--- >> ‘-v LEVEL’ >> ‘--verbosity=LEVEL’ >> Use the given verbosity LEVEL, an integer. Choosing 0 means that >> no output is produced, 1 is for quiet output; 2 is similar to 1 but >> it additionally displays download URLs; 3 shows all the build log >> output on standard error. >> --8<---------------cut here---------------end--------------->8--- > > Maybe, we could add an option as ’--list-verbosity’ which would display > that information. > > Well, the main issue, IMHO, is that the option ’--verbosity’ is not > shared across various command-line scripts, but implemented script per > script, IIRC. Oh, is it? That's not great. I've never used it, but Guix already soft-depends on guile-lib, and guile-lib provides a logging library. Perhaps if we used that we would benefit from some standardized and global way to perform logging across at least the host-side code? And that'd help more straightforwardly reason and explain the levels? I have experience with logging from Python and would like to have a similar tool available in Guix. Instead of adding pk all over the place when debugging enabling the debug level (assuming we've added a few well placed debug level logging directives in the code) would help trace execution and pinpoint where things go wrong easily. -- Thanks, Maxim