unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pierre Neidhardt <mail@ambrevar.xyz>
To: "Ryan Prior" <ryanprior@hey.com>,
	zimoun <zimon.toutoune@gmail.com>,
	"Ludovic Courtès" <ludo@gnu.org>,
	"Development of GNU Guix and the GNU System distribution"
	<guix-devel@gnu.org>
Subject: Re: GNU Guix 1.2.0rc2 available for testing!
Date: Fri, 20 Nov 2020 10:34:31 +0100	[thread overview]
Message-ID: <87v9e04biw.fsf@ambrevar.xyz> (raw)
In-Reply-To: <b6d0a6c6444ba43b4434de3ca077e57bd5ea773d@hey.com>

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Ryan Prior <ryanprior@hey.com> writes:

> I'm glad for the "without-tests" option because when I'm working on
> packages with a test suite that takes more than a few seconds, I like to
> make sure that the rest of everything is working before I start running
> the tests.

Exactly, that was my original thought.

> Another thing I'd like is an option to build a package reusing the state
> from a previous build. If a package I'm working on takes a minute or
> longer to build and I'm having some sort of difficulty, it's obnoxious
> to wait for that to complete again after every cycle. It could be near
> instantaneous if I could re-use a cached build, which is doable in
> Docker, Earthly, and other containerized build systems.

You can kind of do that manually now.
Build with the -K option and when it fails, drop to the temporary
directly, source the `environment-variables` file, fix the code or calls
then proceed.

Obviously reusing cached build would be nicer.

Maybe even better would be debugger access to the daemon.  On build
error we would be dropped in the debugger in the stack frame where it
errored.  We would fix it, then continue, in the most traditional Lisp
fashion!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

  reply	other threads:[~2020-11-20  9:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18 18:53 GNU Guix 1.2.0rc2 available for testing! Ludovic Courtès
2020-11-19  2:24 ` zimoun
2020-11-19  8:34   ` Pierre Neidhardt
2020-11-20  3:13     ` Ryan Prior
2020-11-20  9:34       ` Pierre Neidhardt [this message]
2020-11-22  2:53         ` Maxim Cournoyer
2020-11-20  9:23   ` zimoun
2020-11-20 11:25     ` 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=87v9e04biw.fsf@ambrevar.xyz \
    --to=mail@ambrevar.xyz \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=ryanprior@hey.com \
    --cc=zimon.toutoune@gmail.com \
    /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).