Re: Separating test inputs?

[Liliana Marie Prikler]

Am Dienstag, dem 02.01.2024 um 10:14 +0200 schrieb Saku Laesvuori:
> > A better test infrastructure in Guix would probably be good, but is
> > not ready yet. Would it make sense, however, to split out those
> > inputs only needed for testing?
> > 
> > Such a step would probably make bootstrapping new architectures a
> > lot easier. It would also reduce the dependency graph in Guix,
> > since tests are not needed to either build or use a package.
> > 
> > In Debian, test prerequisites are annotated awkwardly with
> > <!nocheck> in the build prerequisites. (I think Guix calls them
> > native-inputs.)
> > You can see some of Debian's funny notations here [1] and here. [2]
> > 
> > This is a proposal for 'test-inputs'. Any thoughts?
> 
> An additional test-inputs field sounds like a good idea. Maybe the
> test-inputs could be made available just for the test phase (I'd
> assume this could be implemented with add-test-inputs and remove-
> test-inputs phases) so that they would be isolated from other parts
> of the build process.
Adding inputs only during check will not work for build systems that
actually need a configure phase, such as gnu, cmake, or meson.  Python
might be a weird outlier where testing is more loosely coupled from the
build.

I think rather than have a specific category of test inputs, we might
want to have a without-input transformer to remove unwanted inputs from
a package.  Since we have with-input already, it's the obvious thing to
do :)

Cheers