[bug#58365] [PATCH 0/6] Support #:tests? in guile-build-system

[Efraim Flashner <efraim@flashner.co.il>]

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

Top posting to make sure it is read:

Maxime: I understand this has been going back and forth for over a year
now and has been very frustrating, but parts of this email are
unnecessary.  As a maintainer I haven't done enough to try to ease
tensions and find an equitable solution and for that I apologize.

Ludo: Based on the publicly available emails I'm not seeing why this was
held in limbo for so long.  For plenty of packages we have a policy of
writing a patch, submitting it upstream if possible, and carrying it
until we can drop it.  Currently I'm not seeing this as so much
different as either that case or some of the other files we carry in
gnu/packages/aux-files.

To everyone: Please keep in mind if you feel the need to remove the
mailing list from the reply chain if it is because it is something that
really, truly, doesn't need to be sent to everyone or because you'd
rather have it hidden from view.

I am liberally removing parts of the email as I respond below:

On Mon, Nov 20, 2023 at 01:34:12AM +0100, Maxime Devos wrote:
> Hi,
> 
> Op 18-10-2022 om 17:44 schreef Ludovic Courtès:
> > Let me try to clarify what I think can be a fruitful way forward.
> > Again, I agree with the goal you have here, I’m just proposing a
> > different strategy.

Noted

> > To me, the problem that we have is lack of a standard way to run tests
> > in Guile packages that don’t use Autotools.  That, in turn, leads to
> > duplication in package definitions—whether it’s ‘check’ phases in Guix
> > or something similar in Debian and other distros.

Noted

> Err, this is the same for Autotools Guile packages -- Autotools Guile
> packages have to copy test-driver.scm too (or do (exit 1)-style tests, but
> those aren't really the tests this patch series).  You can drop the
> qualifier ‘
> 
> Also, there is, in fact a standard way to run tests in Guile packages: copy
> the test-driver.scm (and in case of Autotools, parts of the Makefile.am from
> another Guile package).
> 
> While this does sound like _a_ problem, it is not a problem this patch
> series is about and hence not _the_ problem (see later for details).

Noted.

Referring back to duplicated code above from Ludo, I wonder about using
the test-driver script by default vs adding it per-package, but I don't
have a good handle on how many packages are waiting to use it.

> > Instead of addressing it downstream (in Guix), my suggestion would be to
> > address it upstream—that is, to promote one way to run SRFI-64 test
> > suites, for example with a new “guild test” command.
> 
> But Guix is the upstream (I mentioned this in the first e-mail *) -- AFAICT,
> Guix has the latest version of test-driver.scm, and AFAICT Guix is where
> test-driver.scm + parts of Makefile.am is copied from.
> 
> (*) and also right in the e-mail you were responding to:

Sounds like Guix is the upstream of test-driver.scm and guile, as the
upstream language in this build-system, could absorb it and make it
available through 'guild test'.

> > Going by "git log build-aux/test-driver.scm", Guix is the upstream, not
> > Guile, though I suppose it could eventually be moved to Guile if desired
> > by both.
>
> > That “guild test” command would probably be very similar to
> > ‘build-aux/test-driver.scm’.  As you note, this script is battle-tested
> > and provides useful functionality.  If we would turn it into a (scripts
> > test) module, that ‘guild’ would pick up, then we’d have a good start.
> > With proper documentation, programmers who use Guile would have an
> > incentive to use this method; packagers would benefit because the
> > default ‘check’ phase would boil down to invoking “guild test”.
> > 
> > I hope this clarifies my proposal.  WDYT?

Sounds like a good long-term plan.  That said, it is something to work
out at a later date, not in this patch series.

> I think that is a clear proposal, I'm not interested in implementing it, I
> consider it out-of-scope and something that could be done separately from
> this patch series.

Noted

> Finding who should be the upstream of test-driver.scm or finding a new home
> for test-driver.scm is not at all the point of this patch series -- the
> point is to support #:tests? in guile-build-system, and for that a test
> driver is needed, and look, there is a test driver right here in the Guix
> repo, let's package it so that it becomes available to the build/test code
> of guile-build-system (and as a bonus, it makes test-driver.scm more
> discoverable).

Sounds reasonable.

> IOW, going back to your ‘I'm just proposing a different strategy’ comment --
> you aren't proposing a different strategy for the patch series, you are
> proposing something supplemental, and that ‘something supplemental’ is
> something for guile-devel@, not guix@.

I ignored this the first time through because it has to do with the
guile-build-system and that's not something I've ever looked at.

It sounds like the best *long term* option is to move this upstream to
guile or to package it separately in its own repository.  Seeing as it's
been a year since this thread started I don't see that as a reason to
hold anything up.

In the immediate term, it looks like this patch set (which I haven't
tested, but noticed the patches seem to be in the wrong order) would
bring testing to the guile packages, which everyone agrees is a Good
Thing™.  Lets get it fixed up and merged and any other bits can be
worked on at a later date.  If no one else comes forward to make sure
that all the pieces work the way they're supposed to I will take care of
it myself in about a week.

In the mean time, please try to keep the conversation at least civil,
and remember that we're all bound by the Code of Conduct while involved
with Guix.


-- 
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 --]