[bug#55653] [PATCH] guix: Add syntactic sugar for profile generation.

[Ludovic Courtès]

Hallo!

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> If it reads like that, then that's probably a mistake somewhere.  My
> actual proposal to allow both of the following:
>
> (package
>   other-fields ...
>   (manifest some-manifest))
> (package 
>   other-fields ...
>   (packages (list bash coreutils emacs ...)))

Oh OK, I got it wrong, sorry.

Still I’m not a fan of having syntax that looks like a field but is not
an actual field, if we can avoid it.  I prefer to expose the data
structure as it exists and, if needed, to build abstractions on top of
it.  (The ABI issue that Maxime mention is real but I don’t think it’s a
big problem in practice.)

>> > > However, if that helps, we could have a procedure, like:
>> > > 
>> > >   (define (packages->profile name packages)
>> > >     (profile (name name) …))
>> > > 
>> > > Thoughts?
>> > I do think syntactic constructors feel better here, because the end
>> > goal would be embedding things in (thunked) configuration fields. 
>> > Having a procedure might be acceptable, but feels more clunky in
>> > the context of Guix.
>> 
>> To me, ‘packages->profile’ doesn’t look any more clunky than
>> ‘packages->manifest’ or similar procedures.
>> 
>> Do you think a procedure like this would address the verbosity
>> problem that prompted you to propose this patch?
> I don't think it does tbh.  We currently have two implementations of
> packages->profile-entry, one for Guix System, one for Guix Home, which
> at the time of writing are exactly the same.

Looks like we could start by factorizing it.  :-)

> My use case of naming profiles would be served by such a procedure,
> but using a syntactic constructor has other benefits in that all of
> the fields of the profile become accessible.  That means that users
> could (once profile management via Guix Home is implemented) for
> instance run less hooks or additional hooks for certain profiles,
> allow collisions, use relative symlinks, etc. for basically free, not
> to mention that changes which break record ABI (such as added fields)
> get promoted directly through syntax but not through a plain
> procedure.

This is an argument (and probably a good one) in favor of using
<profile> records.  I don’t read it as an argument in favor of the
‘packages’ pseudo field though?

Thanks,
Ludo’.