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