guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#68946] [PATCH v2] guix: Add logging module.


From: Maxim Cournoyer
Subject: [bug#68946] [PATCH v2] guix: Add logging module.
Date: Sun, 25 Feb 2024 09:32:56 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>>> My concern with logging is that it’s not a good fit for the functional
>>> parts (unless it has a functional interface like ‘pk’, but that’s still
>>> sorta “cluttering” otherwise functional code), and I’m not sure which
>>> imperative part it could be used for (I don’t doubt there’s such a
>>> thing, but I lack imagination).
>>
>> I understand the concern, but I think to be able to trace execution
>> easily at run time with a simple `--log-level=debug' would provide value
>> enough (as a developer aid) to justify it.
>
> Again, I lack imagination; where would you use it today?
>
> I think we should only add this facility once it has at least one user.
> Otherwise people using ‘--log-level’ would be disappointed.  :-)

OK; I've added some basic logging to get the ball rolling; it's
currently limited to showing the parsed arguments used with the guix
command run, it looks like so:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix --log-level=debug build hello
2024-02-25 02:58:13 guix/logging.scm:92:5: (run-guix-command) DEBUG: logging 
initialized
2024-02-25 02:58:13 guix/ui.scm:2296:11: (run-guix-command) INFO: running guix 
command `build' with args: (hello)
2024-02-25 02:58:13 guix/scripts/build.scm:741:3: (guix-build) INFO: 'guix 
build' parsed options: ((argument . hello) (build-mode . 0) (graft? . #t) 
(substitutes? . #t) (offload? . #t) (print-build-trace? . #t) 
(print-extended-build-trace? . #t) (multiplexed-build-output? . #t) (verbosity 
. 3) (debug . 0))
/gnu/store/kf9cgiq5a2bbxf89h72scl6b5f4jmjpf-hello-2.12.1
--8<---------------cut here---------------end--------------->8---

While this is not super useful yet, we can see where execution started,
and which options were passed to the lower level command API, which
could be a helpful entry-point discoverability hint to a new hacker
wanting to add a switch or look into how a particular command is implemented.

I'll send a v3 with it soon.

-- 
Thanks,
Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]