Re: guix lint should support overrides
On 2022-09-05, zimoun wrote: > On mer., 24 août 2022 at 14:06, Vagrant Cascadian 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 signature.asc Description: PGP signature
Re: guix lint should support overrides
Hi Vgrant, On mer., 24 août 2022 at 14:06, Vagrant Cascadian 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
Hi all, On Tue, Aug 23, 2022 at 3:23 PM Vagrant Cascadian 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
Re: guix lint should support overrides
Hi, Maxime Devos 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
On Wed, Aug 24, 2022 at 10:08:27AM +0200, zimoun wrote: > Hi Vagrant, > > On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian 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 אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: guix lint should support overrides
On 2022-08-24, zimoun wrote: > On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian 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 signature.asc Description: PGP signature
Re: guix lint should support overrides
On 24-08-2022 10:08, zimoun wrote: Hi Vagrant, On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian 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. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: guix lint should support overrides
Hi Vagrant, On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian 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
guix lint should support overrides
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 signature.asc Description: PGP signature