From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: shortening the git test suite Date: Sat, 07 Jul 2018 23:37:56 +0200 Message-ID: <87y3emsp57.fsf@elephly.net> References: <87r2ko6pby.fsf@elephly.net> <87r2ki2hso.fsf@gmail.com> <87fu0y11ir.fsf@elephly.net> <87sh4wgrc3.fsf@netris.org> <87va9s9itb.fsf@gnu.org> <87a7r3gfmx.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbuuO-0000JG-S0 for guix-devel@gnu.org; Sat, 07 Jul 2018 17:38:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbuuK-0004bl-MP for guix-devel@gnu.org; Sat, 07 Jul 2018 17:38:24 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21104) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fbuuK-0004al-G8 for guix-devel@gnu.org; Sat, 07 Jul 2018 17:38:20 -0400 In-reply-to: <87a7r3gfmx.fsf@netris.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: Mark H Weaver Cc: guix-devel@gnu.org Mark H Weaver 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=E2=80= =99t >> 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 > , 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=E2=80=99ve encountered enough for = which this would not work. A change to the =E2=80=9Cbuild model=E2=80=9D might be to allow for build d= irectories 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