guix lint should support overrides

guix lint should support overrides

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

I love guix lint! The vast majority of the time I even use it!

But... sometimes a guix lint suggestion isn't appropriate, at which
point it becomes noise for future contributors of that package.

tt might not be possible, or at least not worth the effort, to improve
guix lint to catch that particular case. Sometimes human judgement is
still valuable.

But, because there is no way to silence a particular inappropriate
suggestion from guix lint, it becomes noise, and each person evaluating
the results of the package in the future then needs to take time to
figure out if guix lint is wrong, or something should be changed.

You could add comments to the package about which lint warnings are
inappropriate, but would it be better if you could just override the
suggestion programatically, hiding it from the eyes and minds of the
valuable and limited humans with their great powers of judgement?

Debian's correlary, lintian, has a mechanism to do exactly this, where
you list the various things that aren't appropriate, and can even
comment on why, in a way that lintian basically hides the issue from
further attention.


The downside is this becomes one more thing to maintain... in exchange
for making the output having a higher degree of relevency in "guix lint"
output, so you can be more confident that someone hasn't already looked
at a given issue and decided it was best to just ignore it (not that
that will not ever happen anymore, but still).


Thoughts?


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: guix lint should support overrides

[zimoun]

Hi Vagrant,

On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian <vagrant@debian.org> wrote:

> But, because there is no way to silence a particular inappropriate
> suggestion from guix lint, it becomes noise, and each person evaluating
> the results of the package in the future then needs to take time to
> figure out if guix lint is wrong, or something should be changed.

Do you have some packages as example?  In order to be concrete about the
false-positive and how to programatically fix them.

For instance, do you mean exclude on specific checker for one specific
package?  Or teach one specific checker for one specific package in
order to avoid an error specific to this package running this specific
checker?


> The downside is this becomes one more thing to maintain... in exchange
> for making the output having a higher degree of relevency in "guix lint"
> output, so you can be more confident that someone hasn't already looked
> at a given issue and decided it was best to just ignore it (not that
> that will not ever happen anymore, but still).

The cost for a poor maintenance is low compared to the benefit, IMHO.

For instance, it is boring to run massive lint:

 1. because “guix lint” does not support the option --manifest
 2. because “guix lint” reports some false-positive messages


Cheers,
simon

Re: guix lint should support overrides

[Maxime Devos]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1481 bytes --]


On 24-08-2022 10:08, zimoun wrote:
> Hi Vagrant,
>
> On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian<vagrant@debian.org>  wrote:
>
>> But, because there is no way to silence a particular inappropriate
>> suggestion from guix lint, it becomes noise, and each person evaluating
>> the results of the package in the future then needs to take time to
>> figure out if guix lint is wrong, or something should be changed.
> Do you have some packages as example?  In order to be concrete about the
> false-positive and how to programatically fix them.
>
> For instance, do you mean exclude on specific checker for one specific
> package?  Or teach one specific checker for one specific package in
> order to avoid an error specific to this package running this specific
> checker?

Myself (not Vagrant) I was thinking of the gnu-description linter.

IIRC, there was some package where I proposed to modify the description 
a little to be more informative and fit better in Guix, but then the 
gnu-description proposed to use the upstream description. Consequently, 
it was decided to use the original, IMO worse, description.

Unfortunately I cannot find the relevant e-mails anymore.

This was a true positive, not a false positive, but I think it would 
have been useful to silence the linter there anyway.

At least for these kind of cases, I would go for a package property 
(properties '((silence-linters gnu-description))).

Greetings,
Maxime.


[-- Attachment #1.1.1.2: Type: text/html, Size: 2183 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: guix lint should support overrides

[Ludovic Courtès]

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> IIRC, there was some package where I proposed to modify the
> description a little to be more informative and fit better in Guix,
> but then the gnu-description proposed to use the upstream
> description. Consequently, it was decided to use the original, IMO
> worse, description.
>
> Unfortunately I cannot find the relevant e-mails anymore.
>
> This was a true positive, not a false positive, but I think it would
> have been useful to silence the linter there anyway.
>
> At least for these kind of cases, I would go for a package property
> (properties '((silence-linters gnu-description))).

Yes, properties are the way to go IMO.

Note that there’s already one or two checker-specific properties, such
as ‘lint-hidden-cve’.  We could add more of that if needed.

A higher-level ‘lint-silenced-checkers’ property like you propose (I
think that’s a better name) would also be welcome.

It’s incidentally a good programming task to get started; who’s in?  :-)

Ludo’.

Re: guix lint should support overrides

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

On 2022-08-24, zimoun wrote:
> On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian <vagrant@debian.org> wrote:
>
>> But, because there is no way to silence a particular inappropriate
>> suggestion from guix lint, it becomes noise, and each person evaluating
>> the results of the package in the future then needs to take time to
>> figure out if guix lint is wrong, or something should be changed.
>
> Do you have some packages as example?  In order to be concrete about the
> false-positive and how to programatically fix them.

Off the top of my head, no, though it came up in the course of a
convesation on #guix recently, and it reminded me of advice I've gotten
in the past to just ignore a particular check on a particular package.


> For instance, do you mean exclude on specific checker for one specific
> package?

Yes, this! :)

Maybe something like:

(define-public thispackages
  (package
   (name "thispackages"
   ...
   (lint-overides
    (list
        ;; The upstream name is actually "This Packages", not a typo.
        "typo in description: 'This Packages' should be 'This Package'")) 

And then guix lint would hide or ignore things that would otherwise emit
the strings listed in lint-overrides ... or something like that. Maybe
exact match, maybe get into a little pattern matching, not
sure. Implementation is not my strong point here. :)

You might also want to add a guix lint check for unused overrides
(e.g. something that no longer triggers the issue, either fixed upstream
in guix lint itself, or some other way).


> Or teach one specific checker for one specific package in
> order to avoid an error specific to this package running this specific
> checker?

No. Maybe in some cases this might make sense, but was not what I was
suggesting.


>> The downside is this becomes one more thing to maintain... in exchange
>> for making the output having a higher degree of relevency in "guix lint"
>> output, so you can be more confident that someone hasn't already looked
>> at a given issue and decided it was best to just ignore it (not that
>> that will not ever happen anymore, but still).
>
> The cost for a poor maintenance is low compared to the benefit, IMHO.
>
> For instance, it is boring to run massive lint:
>
>  1. because “guix lint” does not support the option --manifest
>  2. because “guix lint” reports some false-positive messages

Yeah, my suggestion was mostly about trying to address aspects of point
2.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: guix lint should support overrides

[zimoun]

Hi Vgrant,

On mer., 24 août 2022 at 14:06, Vagrant Cascadian <vagrant@debian.org> wrote:

> Maybe something like:
>
> (define-public thispackages
>   (package
>    (name "thispackages"
>    ...
>    (lint-overides
>     (list
>         ;; The upstream name is actually "This Packages", not a typo.
>         "typo in description: 'This Packages' should be 'This Package'")) 
>
> And then guix lint would hide or ignore things that would otherwise emit
> the strings listed in lint-overrides ... or something like that. Maybe
> exact match, maybe get into a little pattern matching, not
> sure. Implementation is not my strong point here. :)

Well, it is possible to turn off one specific checker for one package;
using the ’properties’ field.  However, this “overides” requires more
work. :-)

Basically, the wish is for description and synopsis and mainly for typo,
right?


Cheers,
simon

Re: guix lint should support overrides

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

On 2022-09-05, zimoun wrote:
> On mer., 24 août 2022 at 14:06, Vagrant Cascadian <vagrant@debian.org> wrote:
>
>> Maybe something like:
>>
>> (define-public thispackages
>>   (package
>>    (name "thispackages"
>>    ...
>>    (lint-overides
>>     (list
>>         ;; The upstream name is actually "This Packages", not a typo.
>>         "typo in description: 'This Packages' should be 'This Package'")) 
>>
>> And then guix lint would hide or ignore things that would otherwise emit
>> the strings listed in lint-overrides ... or something like that. Maybe
>> exact match, maybe get into a little pattern matching, not
>> sure. Implementation is not my strong point here. :)
>
> Well, it is possible to turn off one specific checker for one package;
> using the ’properties’ field.  However, this “overides” requires more
> work. :-)

Though a single checker may check multiple things, and only get some of
them "wrong"; seems it would be worth having granularity for individual
checks.

> Basically, the wish is for description and synopsis and mainly for typo,
> right?

No, it seems odd to me to restrict this to particular categories of
checks. I would say any specific lint check might have cases where it is
not practical to fix the lint check, yet is not appropriate for a
particular package.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: guix lint should support overrides

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

On Wed, Aug 24, 2022 at 10:08:27AM +0200, zimoun wrote:
> Hi Vagrant,
> 
> On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian <vagrant@debian.org> wrote:
> 
> > But, because there is no way to silence a particular inappropriate
> > suggestion from guix lint, it becomes noise, and each person evaluating
> > the results of the package in the future then needs to take time to
> > figure out if guix lint is wrong, or something should be changed.
> 
> Do you have some packages as example?  In order to be concrete about the
> false-positive and how to programatically fix them.
> 
> For instance, do you mean exclude on specific checker for one specific
> package?  Or teach one specific checker for one specific package in
> order to avoid an error specific to this package running this specific
> checker?

We have lint-hidden-cve. We also have a number of packages where there
is a string that is just too long but can't reasonably be cut shorter.

> 
> > The downside is this becomes one more thing to maintain... in exchange
> > for making the output having a higher degree of relevency in "guix lint"
> > output, so you can be more confident that someone hasn't already looked
> > at a given issue and decided it was best to just ignore it (not that
> > that will not ever happen anymore, but still).

The 'properties' field isn't mandatory, so if we just didn't add
something it wouldn't be a big deal.

> 
> The cost for a poor maintenance is low compared to the benefit, IMHO.
> 
> For instance, it is boring to run massive lint:
> 
>  1. because “guix lint” does not support the option --manifest
>  2. because “guix lint” reports some false-positive messages
> 
> 
> Cheers,
> simon
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: guix lint should support overrides

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi all,

On Tue, Aug 23, 2022 at 3:23 PM Vagrant Cascadian <vagrant@debian.org> wrote:
>
> Debian's correlary, lintian, has a mechanism to do exactly this, where
> you list the various things that aren't appropriate, and can even
> comment on why, in a way that lintian basically hides the issue from
> further attention.

Overrides would also offer a benefit to 'guix lint' maintainers! A
large proportion of overrides relative to the total incidence suggests
the heuristics should be tuned to reduce nuisance, if possible.

Kind regards
Felix Lechner