Re: shortening the git test suite

[Mark H Weaver <mhw@netris.org>]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> Mark H Weaver <mhw@netris.org> 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.

I suggested a solution to this problem in my paragraph immediately
following the one you quoted above.  Did you see it?  Here it is again:

  In typical cases where "make check" expects to be run from a fully built
  source directory, the main package would typically produce a tarball of
  the built source directory as an additional output.  The test package
  would simply unpack this tarball and run "make check" in it.

       Mark