Re: shortening the git test suite

[Mark H Weaver]

Hi Ludovic,

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> skribis:
>
>> If we feel that very few of our users care about git-svn interop,
>> another option would be to add a lighter variant of 'git' that does not
>> include SVN support.  It would probably be a good idea to have a
>> 'git-minimal' package anyway, for use by our 'git-fetch' origin method.
>> Naturally, only the 'git' package variant that includes SVN support
>> would need to run the SVN tests.
>
> Yeah, I think we could to do something like this in this case.
>
> Instead of ‘git-minimal’, we could have ‘git’ without SVN support, and
> have a separate ‘git-svn’ package.  We can probably arrange for that
> ‘git-svn’ package to only provide the relevant libexec/git-core bits
> (git-svn is just a Perl script anyway.)
>
> Thoughts?

Sure, that sounds good to me.

Whether it makes to have a 'git-minimal' package depends on how many
other optional dependencies could reasonably be removed from it, besides
subversion.  If not much else could be removed, then I suppose there
would be no need for a 'git-minimal' variant.

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

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.

Regarding the build order: ideally, we would run the tests for package
FOO immediately after building FOO, or at least before building anything
that depends on FOO, to avoid wasted work in case the tests fail.  I'm
not sure how best to accomplish this.

What do you think?

      Mark