[aur-general] Fwd: FS#60333: namcap exits 0 when errors found (Task closed)
I noticed that even when namcap prints out errors, it still exits 0. I raised this at: https://bugs.archlinux.org/task/60333 It was closed: Reason for closing: Not a bug Additional comments about closing: namcap runs fine, so exiting with an error makes no sense To me the "reason for closing" is like saying that diff should exit 0 when two files are different because diff ran fine. If namcap is to be used in any automated packaging tools (or even my dodgy script), then it makes sense to have meaningful exit codes. And possibly an option to also have warnings also exit non-0 for the persnickety amongst us. I note that the python source returns 0 and 2, but never 1. I'm a newbie here, but I believe my argument has merit, so I raise it here for possible discussion. -- Tom Hale
On Mon, 8 Oct 2018 13:23:03 +0700
Tom Hale
I noticed that even when namcap prints out errors, it still exits 0.
I raised this at: https://bugs.archlinux.org/task/60333
It was closed:
Reason for closing: Not a bug Additional comments about closing: namcap runs fine, so exiting with an error makes no sense
To me the "reason for closing" is like saying that diff should exit 0 when two files are different because diff ran fine.
If namcap is to be used in any automated packaging tools (or even my dodgy script), then it makes sense to have meaningful exit codes. And possibly an option to also have warnings also exit non-0 for the persnickety amongst us.
I note that the python source returns 0 and 2, but never 1.
I'm a newbie here, but I believe my argument has merit, so I raise it here for possible discussion.
namcap's output is informational, nothing more. Taking it as gospel or using it as any kind of automated checking instead of actually reading the output is not sane.
On 8/10/18 1:35 pm, Doug Newgard via aur-general wrote:
namcap's output is informational, nothing more. Taking it as gospel or using it as any kind of automated checking instead of actually reading the output is not sane.
For greater specificity, the informational output can be split into: * Information (-i) * Warnings * Errors Unless they are badly named, are there any cases in which an error is not an error? And if so, that rule could be excluded with --rules=, again making the exit code useful. -- Tom Hale
On Mon, 8 Oct 2018 13:43:28 +0700
Tom Hale
On 8/10/18 1:35 pm, Doug Newgard via aur-general wrote:
namcap's output is informational, nothing more. Taking it as gospel or using it as any kind of automated checking instead of actually reading the output is not sane.
For greater specificity, the informational output can be split into:
* Information (-i) * Warnings * Errors
Unless they are badly named, are there any cases in which an error is not an error?
And if so, that rule could be excluded with --rules=, again making the exit code useful.
Every single error can be a false positive.
On 10/8/18 2:23 AM, Tom Hale wrote:
I noticed that even when namcap prints out errors, it still exits 0.
I raised this at: https://bugs.archlinux.org/task/60333
It was closed:
Reason for closing: Not a bug Additional comments about closing: namcap runs fine, so exiting with an error makes no sense
To me the "reason for closing" is like saying that diff should exit 0 when two files are different because diff ran fine.
If namcap is to be used in any automated packaging tools (or even my dodgy script), then it makes sense to have meaningful exit codes. And possibly an option to also have warnings also exit non-0 for the persnickety amongst us.
I note that the python source returns 0 and 2, but never 1.
I'm a newbie here, but I believe my argument has merit, so I raise it here for possible discussion.
namcap does unreliable things like repeatedly fail with: PKGBUILD (qbittorrent) E: Missing description in PKGBUILD because it can't tell that the description is in fact in the split package functions. It tells me that split PKGBUILDs need all the split package dependencies as makedepends, even though that's clearly wrong. Its detection of shebang dependencies, unused pthread libraries, "unused" dependencies for python module dependencies, and more, are notoriously flaky. Its recommendation that packages with fonts, desktop files, mime database files, etc. should have random dependencies in order to ensure the respective pacman hooks are triggered... is something I simply consider to be totally wrong. I'd agree namcap can be useful, but I don't give any particular credence to the exit code and I think you should always review every error. If you just want to know what it found, I guess you could list the number of output lines. Also, I have just as many false positives that claim to be errors, as I have false positives that claim to be warnings. tl;dr I didn't close that bug, but I can see the rationale Doug had when he closed it. -- Eli Schwartz Bug Wrangler and Trusted User
participants (3)
-
Doug Newgard
-
Eli Schwartz
-
Tom Hale