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