unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: David Dashyan <mail@davie.li>, Guix Help <help-guix@gnu.org>
Subject: Re: Bug? Importing (gnu rest ...) fails due to lack of patch files on build side.
Date: Sun, 25 Apr 2021 18:24:57 +0200	[thread overview]
Message-ID: <f2aa26f2fba3e080bd528c0ab10ebb121483aac4.camel@telenet.be> (raw)
In-Reply-To: <87blajj0kh.fsf@davie.li>

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

David Dashyan schreef op ma 12-04-2021 om 12:48 [+0300]:
> Hello Guix!
> 
> I've been having lots of fun with derivations and gexps lately :)
> 
> There are couple of quirks I stumbled upon and I'm not sure whether It's
> a bug or I'm doing weird things.
> 
> Take a look at this snippet:
> 
> (define select?
>   (match-lambda
>     (('guix  'config)   #f)
>     (('guix  rest ...)  #t)
>     (('gnu   rest ...)  #t)
>     (_ #f)))
> 
> (with-store store
>   (let* ((exp (with-extensions (list guile-gcrypt)
>                 (with-imported-modules
>                     `(((guix config) => ,(make-config.scm))
>                       ,@(source-module-closure
>                          '((gnu packages base)) #:select? select?))
>                   #~(pk 'hello))))
>          (drv (run-with-store store
>                 (mlet %store-monad ((drv (gexp->script "error" exp)))
>                   (return drv)))))
>     (build-derivations store (list drv))))
> 
> Here I building derivation producing dummy script that pk-ing 'hello.
> The point really is to try to include source module closure containing
> (gnu packages base), or really almost any (gnu rest ..) module that
> requires loading package patches.  As I found looking at .drv file
> dependencies patch files are not included there.
> 
> Here is the tail of error trace-back:
> 
> 222:17 11 (map1 (((gnu packages gnuzilla)) ((gnu packages #)) # ?))
>   3297:17 10 (resolve-interface (gnu packages gnuzilla) #:select _ # ?)
> In ice-9/threads.scm:
>     390:8  9 (_ _)
> In ice-9/boot-9.scm:
>   3223:13  8 (_)
> In ice-9/threads.scm:
>     390:8  7 (_ _)
> In ice-9/boot-9.scm:
>   3507:20  6 (_)
>    2806:4  5 (save-module-excursion _)
>   3527:26  4 (_)
> In unknown file:
>            3 (primitive-load-path "gnu/packages/gnuzilla" #<procedur?>)
> In ice-9/eval.scm:
>    626:19  2 (_ #<directory (gnu packages gnuzilla) 7fffee6206e0>)
>    293:34  1 (_ #(#(#(#(#(#(#(#(#(#<direc?> ?) ?) ?) ?) ?) ?) ?) ?) ?))
>     159:9  0 (_ #(#(#(#(#(#(#(#(#(#<direc?> ?) ?) ?) ?) ?) ?) ?) ?) ?))
> 
> ice-9/eval.scm:159:9: ERROR:
>   1. &formatted-message:
>       format: "~a: patch not found\n"
>       arguments: ("icecat-use-older-reveal-hidden-html.patch")
> builder for `/gnu/store/7g4kk1ncyh2s3yb55rhpblks4z3bf27h-module-import-compiled.drv' failed with exit code 1
> cannot build derivation `/gnu/store/ksjs8j167mgj1bpqvqnf0rci9pv7ib3k-error.drv': 1 dependencies couldn't be built
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> ERROR:
>   1. &store-protocol-error:
>       message: "build of `/gnu/store/ksjs8j167mgj1bpqvqnf0rci9pv7ib3k-error.drv' failed"
>       status: 100
> 
> So again.  Is it supposed to work? I think it could have gone unnoticed
> because after searching through guix repo I found that (gnu rest ...)
> are generally not included in with-imported-modules.

No, it is not supposed to work!  Only guix/build/... and gnu/build/utils/...
(and maybe others I forgot) are supposed to be imported, so source-module-closure
excludes other modules.  The reason is that gnu/packages/*.scm are supposed to be
changeable without causing any change in derivation hash (and therefore resulting
in rebuilds).

> Some context to why am I doing it in the first place.
> I found this out while I was implementing "guix-cloud-init" service.

Instead of importing (gnu packages ...), you could use
(with-extensions (list guix) ...), where guix is the guix package.
Then there's no need for with-imported-modules IIUC.
That package isn't always the newest though (it is primarily used
for the guix-daemon, for cuirass, emacs-guix and some others),
so consider using an inferior or something.

> Some context to why am I doing it in the first place.
> I found this out while I was implementing "guix-cloud-init" service.
> The service to simplify guix deployment to digialocean, aws and others.
> Cloud-init is widely used way of configuring cloud vm instances and it
> works by providing metadata via mounted storage or link-local address
> http endpoint.  This includes ip addresses, devices, ssh keys etc...  So
> given you have a guix image with guix-cloud-init service you can upload
> to your cloud and it will "just work". :)

Do you know about "guix deploy"?

> So my thinking was that I will write shepherd-root-service extension
> that will query metadata import (gnu services ...) modules and run them
> with values gotten from metadata.
Not sure what you're trying to do there. ‘query metadata import’ and
‘run them with values from metadata’ is a bit vague.

> To be honest it feels a bit hackish
> to me, but I didn't find any other ways to make such service and reuse
> existing code.
> 
> Comments are much appreciated!
> 
> P.S. Side note to macrologysts out there...
> If I embed select? into with-imported-modules form like so:
> 
> (with-imported-modules
>     `(((guix config) => ,(make-config.scm))
>       ,@(source-module-closure
>          '((gnu packages base))
>          #:select? (match-lambda
>                      (('guix  'config)   #f)
>                      (('guix  rest ...)  #t)
>                      (('gnu   rest ...)  #t)
>                      (_ #f))))
>   #~(pk 'hello))

I wonder what would happen if you replace #t with
(and (list rest ...) #t)?  

> Any ideas why is that?

There seems to be some kind of hygiene problem here.
Perhaps take a look at the definition of with-imported-modules
and match-lambda.

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

  parent reply	other threads:[~2021-04-25 16:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12  9:48 Bug? Importing (gnu rest ...) fails due to lack of patch files on build side David Dashyan
2021-04-13 22:10 ` David Dashyan
2021-04-16 14:10   ` Joshua Branson
2021-04-17 21:39     ` David Dashyan
2021-04-25 16:24 ` Maxime Devos [this message]
2021-04-27 17:03   ` David Dashyan
2021-04-27 17:36     ` Maxime Devos

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=f2aa26f2fba3e080bd528c0ab10ebb121483aac4.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=help-guix@gnu.org \
    --cc=mail@davie.li \
    /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.
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).