guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26023: [PATCH] gexp: Expose functions to allow creating derivation b


From: Ludovic Courtès
Subject: bug#26023: [PATCH] gexp: Expose functions to allow creating derivation builders.
Date: Thu, 09 Mar 2017 11:44:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Hello!

Roel Janssen <address@hidden> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <address@hidden> skribis:
>>
>>> Ludovic Courtès writes:
>>>
>>>> Hello!
>>>>
>>>> Roel Janssen <address@hidden> skribis:
>>>>
>>>>> I would like to add the following two functions to the public interface
>>>>> of the gexp module.
>>>>>
>>>>> This makes writing custom derivation builders easier for external
>>>>> projects.
>>>>
>>>> Out of curiosity, how do you use them?
>>>>
>>>> I’m asking because they’re not too bad but not too nice an interface
>>>> either, especially ‘load-path-expression’, and I’d expect the use cases
>>>> to be covered by ‘gexp->script’ & ‘gexp->file’.
>>>>
>>>> Ludo’.
>>>
>>> Here's how I use it:
>>>
>>> (define* (process->bash-engine-derivation proc #:key (guile 
>>> (default-guile)))
>>>   "Return an executable script that runs the PROCEDURE described in PROC, 
>>> with
>>> PROCEDURE's imported modules in its search path."
>>>   (let ((name (process-full-name proc))
>>>         (exp (process-procedure proc))
>>>         (out (process-output-path proc)))
>>>     (let ((out-str (if out (format #f "(setenv \"out\" ~s)" out) "")))
>>>       (mlet %store-monad ((set-load-path
>>>                            (load-path-expression (gexp-modules exp))))
>>>         (gexp->derivation
>>>          name
>>>          (gexp
>>>           (call-with-output-file (ungexp output)
>>>             (lambda (port)
>>>               (use-modules (ice-9 pretty-print))
>>>               (format port "#!~a/bin/bash~%" (ungexp bash))
>>>               ;; Now that we've written all of the shell code,
>>>               ;; We can start writing the Scheme code.
>>>               ;; We rely on Bash for this to work.
>>>               (format port "read -d '' CODE <<EOF~%")
>>>               ;; The destination can be outside of the store.
>>>               ;; TODO: We have to mount this location when building inside
>>>               ;; a container.
>>>               (format port "~a" (ungexp out-str))
>>>               (format port
>>>                       "~%;; Code to create a proper Guile 
>>> environment.~%~a~%"
>>>                       (with-output-to-string
>>>                         (lambda _ (pretty-print '(ungexp set-load-path)))))
>>>               (format port ";; Actual code from the procedure.~%~a~%"
>>>                       (with-output-to-string
>>>                         (lambda _ (pretty-print '(ungexp exp)))))
>>>               (format port "EOF~%")
>>>               (format port "~a/bin/guile -c \"$CODE\"~%" (ungexp guile))
>>>               (chmod port #o555)))))))))
>>>
>>> If you have a suggestion on how to avoid using them, I'd love to hear it.
>>
>> In theory you could put the Scheme code in a separate file (created with
>> ‘gexp->script’), or avoid Bash altogether, but perhaps none of these is
>> an option?
>
> No, it's meant to build runnable scripts that can be run by a job
> scheduling system (Sun Grid Engine).  It's configured to just run a bash
> script (yes, really bash, not just a shell script) with some additional
> syntax.  (For the sake of the example, I gave a shorter version that
> "only" generates the regular bash script.

Oh, I see.

> Perhaps we can come up with a better interface for the gexp module to
> handle these cases.  I will give this some thought.

In the meantime, you can go ahead and expose these two procedures, it’s
not that bad either.  Please add a reference to this issue in the commit
log.

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]