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