Re: shortening the git test suite

[Ricardo Wurmus]

Mark H Weaver <address@hidden> writes:

>>> Also, looking ahead, I think it would be great if we could eventually
>>> move to a model where the tests of some packages are split off into
>>> separate derivations.  Similarly, we could work toward splitting off
>>> documentation generation to separate derivation for selected packages.
>>> The most important advantage to this approach is that it would allow
>>> inputs needed only for tests or docs to be omitted from the inputs of
>>> the main package.  I expect that this will in many cases be needed to
>>> prevent circular dependencies, and it could also greatly reduce the
>>> amount of rebuilding needed after updating certain packages.
>>
>> Currently if test fails, the whole derivation fails, and you can’t
>> install your package.  If tests were run separately, this would no
>> longer hold: you could get your package regardless of whether tests
>> fail.
>
> Indeed, and I agree that we would need to address this.
>
>> How would you address this?  I guess that calls for a new build
>> model, no?
>
> I'm not sure what you mean by "build model", whether you are talking
> about the daemon interface or something else, but I think the changes
> could be confined to the Guix user interface.  A field could be added to
> <package>, somewhat similar to 'replacement', but pointing to a package
> object which runs tests, or perhaps a list of package objects.  The guix
> client could simply add the test packages to the list of derivations to
> build.  This could be inhibited via a "--no-tests" guix build option.

A problem that would need solving is that tests often depend on the
build directory, which is different from what is installed (and ends up
in the store).  The build directory is lost.

This is not true for all packages, but I’ve encountered enough for which
this would not work.

A change to the “build model” might be to allow for build directories to
be provided as inputs to a derivation.  (If this were to be implemented
developers could use that as a way to debug failed builds by keeping the
build directory, make changes, and continuing the build using the
modified build directory, but this feature would have to be heavily
guarded from being abused as a means to get stateful builds into the
store.)

--
Ricardo