GNU bug report logs - #74135
[PATCH 1/2] gnu: Improve emacs-popwin definition.

Previous Next

Full log

Message #17 received at 74135 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
Cc: Andrew Tropin <andrew <at> trop.in>,
 Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>, 74135 <at> debbugs.gnu.org
Subject: Re: [bug#74135] [PATCH 1/2] gnu: Improve emacs-popwin definition.
Date: Fri, 01 Nov 2024 19:19:30 +0100

Hello,

Rostislav Svoboda <rostislav.svoboda <at> gmail.com> writes:

>> I disagree with the removal of "#:tests? #f". It is more meaningful than
>> simply omitting the keyword. It tells us that the package has tests, but
>> they are difficult or even impossible to run. Without the keyword, it
>> could as well mean: "I didn't bother to check if there are tests".
>
> Which is, in fact, the default behavior of the #:tests parameter. By
> default, we do not run any tests, so why bother verifying their
> existence when they’re unnecessary by default?

By default, the `emacs' build system does not run any test, but many
packages run them nevertheless. Some people, including me, try to run
tests from Emacs packages whenever it is possible. As pointed out, in
this situation, "#:tests? #f" with a reason brings some valuable
information. I simply suggest to keep that line.

>> I have no opinion about the removal of native inputs.
>
> Including emacs-ert-runner - a package designed for "Emacs projects
> tested using ERT" - among native inputs is pointless if no tests are
> executed.

OTOH, it might help anyone trying to make the tests run someday (not all
tests require emacs-ert-runner). But in this package, this may not be
possible ultimately, hence "I have no opinion".

>> I also think the change to version should go in the second patch.
>
> In the first patch, I intended to fix the Guix package definition
> without updating the package itself. That's why I incremented the
> revision number from its default (presumably 0) to 1. The v1.0.2 tag
> corresponds to commit 215d6cb509b11c63394a20666565cd9e9b2c2eab.

There is nothing to "fix". The first version correctly uses the tag
instead of the commit hash. Of course, you can update it in the second
patch. The first version change is unnecessary, please keep the second
one only.

Regards,

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.