[Top][All Lists]

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

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

From: Liliana Marie Prikler
Subject: [bug#55653] [PATCH] guix: Add syntactic sugar for profile generation.
Date: Thu, 02 Jun 2022 18:51:38 +0200
User-agent: Evolution 3.42.1

Am Donnerstag, dem 02.06.2022 um 15:32 +0200 schrieb Ludovic Courtès:
> Hallo!
> Liliana Marie Prikler <> 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.


reply via email to

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