GNU bug report logs - #55653
[PATCH] guix: Add syntactic sugar for profile generation.

Previous Next

Full log

Message #32 received at 55653 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Andrew Tropin <andrewtropin <at> gmail.com>, 55653 <at> debbugs.gnu.org,
 Maxime Devos <maximedevos <at> telenet.be>, zimoun <zimon.toutoune <at> gmail.com>
Subject: Re: bug#55653: [PATCH] guix: Add syntactic sugar for profile
 generation.
Date: Thu, 02 Jun 2022 18:51:38 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.