unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Chris Marusich <cmmarusich@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 32184@debbugs.gnu.org
Subject: bug#32184: ‘guix pack --bootstrap’ is ineffective
Date: Tue, 17 Jul 2018 23:11:56 -0700	[thread overview]
Message-ID: <87r2k1ul77.fsf@gmail.com> (raw)
In-Reply-To: <87k1pu9pv3.fsf@gnu.org>

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

ludo@gnu.org (Ludovic Courtès) writes:

> While preparing the 0.15 release I realized that ‘guix pack --bootstrap’
> had become ineffective.  Concretely, ‘tests/guix-pack.sh’ would attempt
> to build the world.
>
> This is a consequence of c45477d2a1a651485feede20fe0f3d15aec48b39w, which
> introduced a dependency on guile-sqlite3 in derivations that build
> packs, even if they don’t actually produce a ‘db.sqlite’ file in there.
>
> I started looking for solutions, which led me to the patch below.
> That’s quite intrusive and it doesn’t work because then we have a
> similar issue with (guix hash) trying to dlopen libgcrypt.
>
> [...]
>
> diff --git a/guix/scripts/pack.scm b/guix/scripts/pack.scm
> index 6d5d745bc..45eeb2e7b 100644
> --- a/guix/scripts/pack.scm
> +++ b/guix/scripts/pack.scm
>
> [...]
> 
> @@ -717,6 +734,9 @@ Create a bundle of PACKAGE.\n"))
>        (set-build-options-from-command-line store opts)
>  
>        (parameterize ((%graft? (assoc-ref opts 'graft?))
> +                     (guile-sqlite3&co (if (assoc-ref opts 'bootstrap?)
> +                                           (list guile-sqlite3/mock)
> +                                           (guile-sqlite3&co)))
>                       (%guile-for-build (package-derivation
>                                          store
>                                          (if (assoc-ref opts 'bootstrap?)

You mentioned that you felt this change is "quite intrusive."  How is
this more intrusive than using parameters for %graft? and
%guile-for-build to control how things get built?  At first blush, this
seems no worse than what we already doing here.

You also mentioned that the proposed patch doesn't actually work, since
we run into a similar problem with (guix hash) trying to dlopen
libgcrypt.  I applied your patch and ran the test, and I think I see
what you mean.  Somehow (I have to admit, I'm not sure how), the normal
libgcrypt gets pulled in by the derivation, so we have to build it...
Although I suppose it isn't ideal, maybe we can get away with working
around it via similar parameterize tricks?

If the intent of --bootstrap is to enable the tool to run quickly in
tests, then it seems we MUST either find a way to substitute every heavy
dependency (including libgcrypt) with a light replacement (e.g. the
guile-sqlite3/mock you made), or find another way to short-circuit the
build.

Basically, we're manually doing dependency injection here depending on
whether or not --bootstrap was given, right?  Instead of parameterizing
the dependencies, what if we used a dependency injector (or "oracle", or
"container", or whatever you want to call it) that, when invoked, would
give us the dependency that is appropriate for the current context?
Perhaps we could control the context via a single parameter.  For
example, something like this:

    (parameterize ((test-environment? #t))
      (injector-get-dependency guile))

would return the bootstrap guile, but something like this:

    (parameterize ((test-environment? #f))
      (injector-get-dependency guile))

would return the usual guile.  This isn't much different from using
parameters like we're already doing, except that it might save us from
having to remember multiple parameters, and it might make the code
cleaner by hiding the dependency selection/construction logic behind the
injector abstraction.

What do you think of that idea?

> I’m not sure how to best address it.  Another approach would be to do
> away with ‘--bootstrap’ and instead write those tests as “system tests”
> in a VM, though that’s maybe less satisfactory.

If we ran these tests in a VM as "system tests" (instead of turning
guile-sqlite3&co into a parameter), would we still need to build the
world?

-- 
Chris

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

  reply	other threads:[~2018-07-18  6:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17  9:24 bug#32184: ‘guix pack --bootstrap’ is ineffective Ludovic Courtès
2018-07-18  6:11 ` Chris Marusich [this message]
2018-07-26 13:26   ` Ludovic Courtès
2018-10-19 16:43   ` 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=87r2k1ul77.fsf@gmail.com \
    --to=cmmarusich@gmail.com \
    --cc=32184@debbugs.gnu.org \
    --cc=ludo@gnu.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).