unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: shortening the git test suite
Date: Sat, 07 Jul 2018 23:37:56 +0200	[thread overview]
Message-ID: <87y3emsp57.fsf@elephly.net> (raw)
In-Reply-To: <87a7r3gfmx.fsf@netris.org>


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.

This is not true for all packages, but I’ve encountered enough for which
this would not work.

A change to the “build model” might be to allow for build directories 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

  reply	other threads:[~2018-07-07 21:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-30 19:34 shortening the git test suite Ricardo Wurmus
2018-06-30 23:52 ` Gábor Boskovits
2018-07-01 13:54 ` Marius Bakke
2018-07-05  9:28   ` Ricardo Wurmus
2018-07-02  4:56 ` Mark H Weaver
2018-07-02  8:39   ` Gábor Boskovits
2018-07-05  9:28     ` Ricardo Wurmus
2018-07-05  8:44 ` Chris Marusich
2018-07-05  9:21   ` Ricardo Wurmus
2018-07-06  9:46     ` Gábor Boskovits
2018-07-06 18:19     ` Mark H Weaver
2018-07-06 21:05       ` Ludovic Courtès
2018-07-07  8:07         ` Gábor Boskovits
2018-07-07 16:44         ` Mark H Weaver
2018-07-07 21:37           ` Ricardo Wurmus [this message]
2018-07-08 22:41             ` Mark H Weaver
2018-07-09  7:47               ` Ricardo Wurmus
2018-07-11 12:46           ` Ludovic Courtès
2018-07-12  9:27           ` Chris Marusich
2018-07-08  1:29         ` Mike Gerwitz
2018-07-06 21:09     ` Automatic branch merging upon build completion Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y3emsp57.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=guix-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).