Re: shortening the git test suite

[ludo@gnu.org (Ludovic Courtès)]

Hello,

Mark H Weaver <mhw@netris.org> skribis:

> Why do you say that only upstream needs to worry about it?  I would
> think that you could say the same thing about almost any test suite, but
> there's always the possibility that our particular combination of input
> versions, or the unusual aspects of Guix, might break something that
> upstream doesn't know about.
>
> I would think that git-svn interop is something that any user of the
> git/svn integration needs to worry about.

I agree.

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

> 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.  How would you address this?  I guess that calls for a new build
model, no?

Thanks,
Ludo’.