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

Previous Next

Full log

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
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 15:32:56 +0200

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.

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.  (The ABI issue that Maxime mention is real but I don’t think it’s a
big problem in practice.)

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

Looks like we could start by factorizing it.  :-)

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

Thanks,
Ludo’.

Previous Next

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