Separating test inputs?

Separating test inputs?

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi,

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?

Kind regards
Felix

[1] https://tracker.debian.org/media/packages/libm/libmouse-perl/control-2.5.10-1
[2] https://tracker.debian.org/media/packages/l/lintian/control-2.116.3

Re: Separating test inputs?

[Ricardo Wurmus]

Felix Lechner via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> writes:

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

Native inputs are those that in the context of cross-building need to
run on the host, not the target.  This is not just for test inputs.

Note also that the presence of test inputs has an impact on the build
itself, such as the configure step, the number of build phases, and even
the output.  In short: without tests this would be a different
derivation.  That’s what we do with the “--without-tests”
transformation: we generate new derivations where tests are not run.

We probably could enhance “--without-tests” to also remove some inputs.

-- 
Ricardo

Re: Separating test inputs?

[Saku Laesvuori]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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