From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: shortening the git test suite Date: Sat, 7 Jul 2018 10:07:41 +0200 Message-ID: References: <87r2ko6pby.fsf@elephly.net> <87r2ki2hso.fsf@gmail.com> <87fu0y11ir.fsf@elephly.net> <87sh4wgrc3.fsf@netris.org> <87va9s9itb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e82e410570644614" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbiG4-0005dT-Fn for guix-devel@gnu.org; Sat, 07 Jul 2018 04:07:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbiG3-0007X2-03 for guix-devel@gnu.org; Sat, 07 Jul 2018 04:07:56 -0400 In-Reply-To: <87va9s9itb.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: Guix-devel --000000000000e82e410570644614 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s ezt =C3=ADrta (id=C5=91pont: 2018. j=C3= =BAl. 6., P, 23:05): > Hello, > > Mark H Weaver 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, bu= t > > 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 =E2=80=98git-minimal=E2=80=99, we could have =E2=80=98git=E2= =80=99 without SVN support, and > have a separate =E2=80=98git-svn=E2=80=99 package. We can probably arran= ge for that > =E2=80=98git-svn=E2=80=99 package to only provide the relevant libexec/gi= t-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=E2=80=99= 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? > > One example where this can be seen in action is the dependency of java-jarjar on java-asm-bootstrap. java-asm-bootstrap is java-asm without the tests, it is exactly there to break a dependency cycle. java-asm is a full rebuild using tests. java-asm-bootstrap is defined, while java-asm is define-public-ed (here a full rebuild is involved). I'm not sure that a full rebuild can be worked around in all cases, I guess that sometimes test capabilities are detected at configure time. WDYT? Thanks, > Ludo=E2=80=99. > > --000000000000e82e410570644614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ludovic Court= =C3=A8s <ludo@gnu.org> ezt =C3=AD= rta (id=C5=91pont: 2018. j=C3=BAl. 6., P, 23:05):
Hello,

Mark H Weaver <mhw@n= etris.org> skribis:

> Why do you say that only upstream needs to worry about it?=C2=A0 I wou= ld
> think that you could say the same thing about almost any test suite, b= ut
> 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.=C2=A0 It would probably be a good idea to have a<= br> > 'git-minimal' package anyway, for use by our 'git-fetch= 9; origin method.
> Naturally, only the 'git' package variant that includes SVN su= pport
> would need to run the SVN tests.

Yeah, I think we could to do something like this in this case.

Instead of =E2=80=98git-minimal=E2=80=99, we=C2=A0 could have =E2=80=98git= =E2=80=99 without SVN support, and
have a separate =E2=80=98git-svn=E2=80=99 package.=C2=A0 We can probably ar= range for that
=E2=80=98git-svn=E2=80=99 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<= br> > move to a model where the tests of some packages are split off into > separate derivations.=C2=A0 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<= br> > the main package.=C2=A0 I expect that this will in many cases be neede= d 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=E2=80=99t<= br> install your package.=C2=A0 If tests were run separately, this would no
longer hold: you could get your package regardless of whether tests
fail.=C2=A0 How would you address this?=C2=A0 I guess that calls for a new = build
model, no?


One example where this can be seen in = action is the dependency of java-jarjar on java-asm-bootstrap. java-asm-boo= tstrap is java-asm without the tests, it is exactly
there to brea= k a dependency cycle. java-asm is a full rebuild using tests. java-asm-boot= strap is defined, while java-asm is define-public-ed (here a full rebuild i= s involved). I'm not sure that a full rebuild can be worked around in a= ll cases, I guess that sometimes test capabilities are detected at configur= e time. WDYT?

Thanks,
Ludo=E2=80=99.

--000000000000e82e410570644614--