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

[Liliana Marie Prikler]

Am Donnerstag, dem 02.06.2022 um 15:32 +0200 schrieb 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.
Actually, I too got it wrong in the patch description.  The
implementation and test should be fine though.

> 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.
I can see where you're coming from, but IMHO the content field does not
itself provide a useful abstraction, and changing the profile record +
constructor would itself break ABI.  Thus the syntactic sugar.


> [...]
> > 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?
Indeed, my argument for the pseudo-field is mere readability.  Compare
the four semantically equivalent ways of writing a profile in the test
case I added.

Cheers