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: Wed, 01 Jun 2022 21:43:54 +0200 [thread overview]
Message-ID: <87zgiwtbid.fsf@gnu.org> (raw)
In-Reply-To: <d5426354a02f060f412bbeb45c374d0c563e985c.camel@gmail.com> (Liliana Marie Prikler's message of "Tue, 31 May 2022 20:07:09 +0200")
Hi,
Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> Am Dienstag, dem 31.05.2022 um 15:47 +0200 schrieb Ludovic Courtès:
>> So the goal is to make things slightly more concise than:
>>
>> (profile (content (packages->manifest (list …))))
>>
>> right?
> More or less. However, I also feel that "content" is somewhat
> confusing if it were to be user-facing so I added a syntactic manifest
> noop as well.
OK.
>> We don’t have syntactic sugar like this elsewhere, and I would prefer
>> to remain consistent here.
> We do have origin sha256, which sets both hash-algo and hash-content,
> so it's not unprecedented in my opinion.
‘sha256’ is a backward-compatibility hack for ‘content-hash’, so it’s a
bit different in my view.
To be clear, what I meant is that record construction always look like
this:
(constructor
(field1 value1)
(field2 value2))
whereas here the proposal (IIUC) is:
(constructor
(field1 several values that get bundled together magically))
>> 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?
Thanks,
Ludo’.
next prev parent reply other threads:[~2022-06-01 19:45 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 [this message]
2022-06-01 20:15 ` Liliana Marie Prikler
2022-06-01 20:34 ` Maxime Devos
2022-06-02 13:32 ` Ludovic Courtès
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=87zgiwtbid.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.