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

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 01.06.2022 um 21:43 +0200 schrieb Ludovic Courtès:
> [...]
> 
> > 
> > > We don’t have syntactic sugar like this elsewhere, and I would
> > > prefer to remain consistent here.  
> > We do have origin sha256, which sets both hash-algo and hash-
> > content, so it's not unprecedented in my opinion.
> 
> ‘sha256’ is a backward-compatibility hack for ‘content-hash’, so it’s
> a bit different in my view.
> 
> To be clear, what I meant is that record construction always look
> like this:
> 
>   (constructor
>     (field1 value1)
>     (field2 value2))
> 
> whereas here the proposal (IIUC) is:
> 
>   (constructor
>     (field1 several values that get bundled together magically))
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 ...)))

> > > 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.  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.

Cheers