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 רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted