From: "Ludovic Courtès" <ludo@gnu.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: Andrew Tropin <andrewtropin@gmail.com>,
55653@debbugs.gnu.org, Maxime Devos <maximedevos@telenet.be>,
zimoun <zimon.toutoune@gmail.com>
Subject: [bug#55653] [PATCH] guix: Add syntactic sugar for profile generation.
Date: Thu, 02 Jun 2022 15:32:56 +0200 [thread overview]
Message-ID: <87sfonp4vr.fsf@gnu.org> (raw)
In-Reply-To: <60b305664d635fa72c2162d0e55fe44af3c95461.camel@gmail.com> (Liliana Marie Prikler's message of "Wed, 01 Jun 2022 22:15:06 +0200")
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.
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’.
next prev parent reply other threads:[~2022-06-02 13:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 9:01 [bug#55653] [PATCH] guix: Add syntactic sugar for profile generation Liliana Marie Prikler
2022-05-27 12:39 ` andrew
2022-05-31 13:47 ` Ludovic Courtès
2022-05-31 18:07 ` Liliana Marie Prikler
2022-06-01 19:43 ` Ludovic Courtès
2022-06-01 20:15 ` Liliana Marie Prikler
2022-06-01 20:34 ` Maxime Devos
2022-06-02 13:32 ` Ludovic Courtès [this message]
2022-06-02 15:07 ` Maxime Devos
2022-06-02 16:51 ` Liliana Marie Prikler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfonp4vr.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=55653@debbugs.gnu.org \
--cc=andrewtropin@gmail.com \
--cc=liliana.prikler@gmail.com \
--cc=maximedevos@telenet.be \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.