Hello! Christopher Baines <m...@cbaines.net> skribis:
> Christopher Baines <m...@cbaines.net> writes: > >> I've never worked with this part of Guix before, and some of it is quite >> complex, so I've started by attempting to do the first bit, storing >> warnings as data before outputting them. I've attached a patch. Providing more structure sounds like a good idea to me (though in the end it’s still just text; not sure if that’s good enough for what you had in mind?). >From a UI viewpoint, it’s important that ‘guix lint’ prints warning as they come, rather than eat CPU for some time and eventually spit out everything at once. > From cd16443893afdacf9f3e4d8256cc943a5928aed4 Mon Sep 17 00:00:00 2001 > From: Christopher Baines <m...@cbaines.net> > Date: Mon, 6 May 2019 19:00:58 +0100 > Subject: [PATCH] scripts: lint: Handle warnings with a record type. > > Rather than emiting warnings directly to a port, have the checkers return the > warning or warnings. > > This makes it easier to use the warnings in different ways, for example, > loading the data in to a database, as you can work with the <lint-warning> > records directly, rather than having to parse the output to determine the > package and location. [...] > +(define-record-type* <lint-warning> > + lint-warning make-lint-warning > + lint-warning? > + (package lint-warning-package) > + (message lint-warning-message) > + (location lint-warning-field > + (default #f))) It could be useful to have a ‘checker’ field linking to the checker that produced the warning. > (define (check-not-empty description) > (when (string-null? description) > - (emit-warning package > + (make-warning package > (G_ "description should not be empty") > - 'description))) > + #:field 'description))) This procedure returns either a warning or the unspecified value, which is probably not intended? I suppose a lot of the code is currently written with ‘emit-warning’ in effect position, which will have to be changed. I suppose tests/lint.scm needs to be converted to the new API? Thanks! Ludo’.
