[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Return back original implementation for text-config serialization
From: |
Andrew Tropin |
Subject: |
Re: Return back original implementation for text-config serialization |
Date: |
Wed, 12 Jan 2022 18:05:20 +0300 |
On 2022-01-10 21:12, Liliana Marie Prikler wrote:
> Am Montag, dem 10.01.2022 um 12:49 +0300 schrieb Andrew Tropin:
>> [T]he whole point of escape hatch is to make it possible to reuse
>> existing files directly without any manipulation on them and importer
>> should demonstrate how to do it.
> That'd make more sense if the importer copied bashrc to some well-known
> location (e.g. ~/.config/guix/data/.bashrc) and then used that rather
> than the file it wishes to replace. IIRC that was one suggested
> behaviour of Guix Home in the past, but it didn't get approval because
> users wouldn't typically ask for that copying to happen. If you make
> it so that plain-file is used normally, but add a switch to express
> things in terms of local-file instead, that'd work.
>
> OTOH, I do think local-file is already well-documented on its own, so
> perhaps it'd only take a cookbook entry to show it in combination with
> Guix Home and an explanation as to why Guix Home doesn't do that
> normally while explaining all the caveats.
It seems that current implementation of importer copy files to the
directory provided as command line argument and after that generates a
config file, which refers those files with local-file.
Overall, I think that the importer is not really well-defined both in
terms of purpose and implementation and maybe it will be better to hold
it until it polished.
>> If importer internally do some manipulation (escaping) with the
>> content of the file and places the result in the string in scheme
>> file, user won't be able to replicate such process easily for other
>> services, which not covered by the importer. If I understood
>> correctly what you meant in the first message.
> Yes, the user would have to manually quote every new line of code
> they're adding, but they're free to use all other file-like objects,
> including local-file. Having (bashrc (local-file ".bashrc")), whether
> implemented on top of slurp-file-gexp or not, is inherently dangerous,
> though.
>
From this
>> > The point I'm making is that we shouldn't swap out one bad
>> > abstraction for another, but pave the road towards good
>> > abstractions, e.g. G-expressions in the way the rest of Guix
>> > typically uses them.
>>
>> Actually, for me, the original implementation looks consistent with
>> how the rest of Guix treats G-expressions (uses already known
>> abstraction) and only new one intoduces a new abstraction.
> That's the point. The old style works just like you'd expect it to, it
> becomes a problem when you try to feed it stuff like slurp-file-gexp to
> work around some limitations in a way I'm not convinced makes sense.
>
and this, it looks like you are concerned with local-file, which can
lead to the non-reproducible code, when for example the local-file
refers something outside of the git repo and on another machine the same
config will lead to an error? And slurp-file-gexp additionally hides it
from the user by wrapping local-file. Correct me if I'm wrong.
>> [I]t's already possible to achieve the same [-- merging multiple
>> bashrc snippets into a single file --] with gexps/file-like in both
>> new and old text-config implementations.
> I find the lack of services in your example concerning, but I'll take
> your word for it. In that case, using a gexp for bashrc in the typical
> sense is probably the best idea, but we still need to do something with
> the reliance on slurp-file-gexp.
>
> Cheers
>
>>
> PS:
>> It's offtopic, but when you will have time please take a look at
>> https://issues.guix.gnu.org/52388.
> Hahaha, it's been a month, hasn't it? There's some aesthetic
> unpleasanties, so I'm not sure if I'll upstream it with slight
> stylistic changes or give you some harsher feedback, but I'll try to
> decide this weekend.
>
Yep :) Thank you, will be waiting for it!)
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
Re: Return back original implementation for text-config serialization, Maxime Devos, 2022/01/09
Re: Return back original implementation for text-config serialization, Maxime Devos, 2022/01/09
Re: Return back original implementation for text-config serialization, Ludovic Courtès, 2022/01/18