[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#55653] [PATCH] guix: Add syntactic sugar for profile generation.
From: |
Ludovic Courtès |
Subject: |
[bug#55653] [PATCH] guix: Add syntactic sugar for profile generation. |
Date: |
Wed, 01 Jun 2022 21:43:54 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
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’.
- [bug#55653] [PATCH] guix: Add syntactic sugar for profile generation.,
Ludovic Courtès <=