[bug#49149] [PATCH 4/7] pack: Improve naming of the packs store file names.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

> Maxim Cournoyer schreef op ma 21-06-2021 om 02:12 [-0400]:
>> Instead of just naming them by their pack type, add information from the
>> package(s) they contain to make it easier to differentiate them.
>> 
>> * guix/scripts/pack.scm (manifest->friendly-name): Extract procedure from ...
>> (docker-image): ... here.  Adjust REPOSITORY argument value accordingly.
>> (guix-pack): Derive NAME using MANIFEST->FRIENDLY-NAME.
>> ---
>>  guix/scripts/pack.scm | 44 +++++++++++++++++++++++++------------------
>>  1 file changed, 26 insertions(+), 18 deletions(-)
>> 
>> diff --git a/guix/scripts/pack.scm b/guix/scripts/pack.scm
>> index 7ea97a4b7a..9d4bb9f497 100644
>> --- a/guix/scripts/pack.scm
>> +++ b/guix/scripts/pack.scm
>> @@ -172,6 +172,23 @@ dependencies are registered."
>>    (computed-file "store-database" build
>>                   #:options `(#:references-graphs ,(zip labels items))))
>>  
>> +;;; XXX: The following procedure has to *also* be used in the build side
>> +;;; G-Exp, because PROFILE is passed as a derivation in the tests.
>> +(define define-manifest->friendly-name
>> +  '(define (manifest->friendly-name manifest) [...]))
>>
>> +(eval define-manifest->friendly-name (current-module))
>
> You can avoid 'eval' here by defining 'manifest->friendly-name
> in a separate guix/build/pack-utils.scm module.
> Alternatively, some macroology (untested, may need some tweaks):

Thanks for the feedback!  I tried moving 'manifest->friendly-name' to
(guix build pack), which was already added in an earlier commit, but
that didn't work because (guix profiles) needs to be pulled in for
'manifest-entries' and 'manifest-entry-name', and sadly (guix profiles)
pulls (guix config), which is not possible/desirable on the build side.

> (define-syntax define-gexp-and-expand
>   ((_ variable code code* ...)
>    (begin (define variable #~(code code* ...))
>           code code* ...)))
>
> (define-gexp-and-expand define-manifest->friendly-name
>   (define (manifest->friendly-name manifest)
>     [... docstring]
>     [... all the code]))

I'm not sure how the expansion would be usable in the module it is
defined?  It seems I could manage to get 'manifest->friendly-name' to be
a procedure returning a gexp, but that gexp wouldn't be readily usable
in that module (it could only be used when gexp-unquote from inside
another G-Exp), and the expansion in the macro above doesn't bind any
identifier, unless I'm missing something?

So for now, I'm stuck with the eval, which doesn't seem to bad
considering it's only evaluating a safe, static expression.

Thank you,

Maxim