Early feedback on Guix Home

Early feedback on Guix Home

[Ludovic Courtès]

Hello!

As discussed on IRC a few days ago, I finally gave Guix Home a try and I
like it!

I thought I’d share my first impressions so we can try and address them
in the process of getting it merged.

First, I think one of the main reasons why it took me so long to try it
out is that I was afraid of what would happen at “activation time” (upon
reconfigure).  Were my dot files going to be deleted?  If so, which ones
exactly should I back up?  That led me to look more closely at the code
to better understand what was going to happen.  I found
‘symlink-manager.scm’, which is what I was looking for, but that code is
fairly complex.

Anyway, I backed up a bunch of files :-) and eventually gave it a try,
just to notice that ‘guix home reconfigure’ was very careful about
creating backups of any files it was going to overwrite, and it was also
explicitly saying what it’s doing.  Perfect.

I see two possible improvements:

  1. Make the manual very upfront about that: don’t be afraid, config
     files are backed up at that location, etc.

  2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
     easier to understand what’s going on.

Second, the other thing that stopped me from getting started is the
initial config.  How could I move from all my undisciplined dotfiles to
the single explicit config?  Eventually, I found that starting with
nothing but packages, ‘home-bash-service-type’, and
‘home-ssh-service-type’ was the most reasonable option to begin with.

Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
have a long ‘.ssh/config’ file and I wasn’t going to turn that into
‘ssh-host’ lines by hand.

Possible actions:

  1. Provide a ‘guix home init’ command (or similar) that creates an
     initial Home config based on existing config.

  2. In some cases, such as OpenSSH, provide converters from the native
     format to its Scheme equivalent (maybe?).

  3. For each service, provide an escape hatch: a way for users to
     provide a raw config file.  We do that for all or most of the Guix
     System services, and it helps a lot when people are starting from
     an existing config.

In terms of API, I noticed that in places such as
‘home-bash-configuration’, config snippets are represented as a list of
strings (internally passed to ‘mixed-text-file’).  That forces users to
mix different languages in their .scm file—e.g., half of my Home config
is .bash{rc,_profile} snippets embedded in Scheme strings.  That’s
inconvenient.

Possible action:

  1. Change config records to accept file-like objects instead of
     strings.  That way, users can choose to have snippets inlined (in a
     ‘plain-file’ object) or separate (via ‘local-file’).  See for
     example how ‘tor-configuration->torrc’ does it.

That’s it.  I hope it makes sense to you!

I encourage everyone to give it a spin, fearlessly!
What I did was (roughly):

  git clone https://git.sr.ht/~abcdw/rde
  guix git authenticate \
    "257cebd587b66e4d865b3537a9a88cccd7107c95" \
    "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
    -k origin/keyring
  ./pre-inst-env guix home reconfigure /path/to/home-config.scm

Thanks,
Ludo’.

Re: Early feedback on Guix Home

[Andrew Tropin]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> As discussed on IRC a few days ago, I finally gave Guix Home a try and I
> like it!
>
> I thought I’d share my first impressions so we can try and address them
> in the process of getting it merged.
>
> First, I think one of the main reasons why it took me so long to try it
> out is that I was afraid of what would happen at “activation time” (upon
> reconfigure).  Were my dot files going to be deleted?  If so, which ones
> exactly should I back up?  That led me to look more closely at the code
> to better understand what was going to happen.

Good to know, added a todo to make it clearer in the documentation.

> I found ‘symlink-manager.scm’, which is what I was looking for, but
> that code is fairly complex.

Yep, perhaps it a little monstous)  Maybe cleaning it up is a good idea
before sending the patch to guix.

> Anyway, I backed up a bunch of files :-) and eventually gave it a try,
> just to notice that ‘guix home reconfigure’ was very careful about
> creating backups of any files it was going to overwrite, and it was also
> explicitly saying what it’s doing.  Perfect.
>
> I see two possible improvements:
>
>   1. Make the manual very upfront about that: don’t be afraid, config
>      files are backed up at that location, etc.
>
>   2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
>      easier to understand what’s going on.

Sounds reasonable)

> Second, the other thing that stopped me from getting started is the
> initial config.  How could I move from all my undisciplined dotfiles to
> the single explicit config?  Eventually, I found that starting with
> nothing but packages, ‘home-bash-service-type’, and
> ‘home-ssh-service-type’ was the most reasonable option to begin with.
>
> Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
> have a long ‘.ssh/config’ file and I wasn’t going to turn that into
> ‘ssh-host’ lines by hand.
>
> Possible actions:
>
>   1. Provide a ‘guix home init’ command (or similar) that creates an
>      initial Home config based on existing config.

Xinglu implemented `guix home import`, which creates a simple
home-environment configuration, which contains the same packages as ~/.guix-profile

>   2. In some cases, such as OpenSSH, provide converters from the native
>      format to its Scheme equivalent (maybe?).

It's a good idea and Xinglu also mentioned it, but I find it to be a lot
of extra work, so I propose to postpone it until next time, IMO it's
better to focus on moving Guix Home from rde repo first in the current
state and add new functionality after that step is done, otherwise we
can stuck with wip-guix-home for months.

>   3. For each service, provide an escape hatch: a way for users to
>      provide a raw config file.  We do that for all or most of the Guix
>      System services, and it helps a lot when people are starting from
>      an existing config.

We do it as well, the only difference is that we try to utilize target
program capabilities or slurp-file-gexp helper for that.

The first one means that target configuration format allows to use some
directive to load the content of another file:
https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/ssh.scm#L190
https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/emacs.scm#L200

The second one inlines the content of file directly in configuration.
In most cases it's done by providing a gexp, which reads the content of
the file in the store and returning its content as a string to make
mixed-text-file to add it to the target configuration.
https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/emacs.scm#L208

> In terms of API, I noticed that in places such as
> ‘home-bash-configuration’, config snippets are represented as a list of
> strings (internally passed to ‘mixed-text-file’).  That forces users to
> mix different languages in their .scm file—e.g., half of my Home config
> is .bash{rc,_profile} snippets embedded in Scheme strings.  That’s
> inconvenient.

Can you elaborate on that please, ideally with some examples.

> Possible action:
>
>   1. Change config records to accept file-like objects instead of
>      strings.  That way, users can choose to have snippets inlined (in a
>      ‘plain-file’ object) or separate (via ‘local-file’).  See for
>      example how ‘tor-configuration->torrc’ does it.
>
> That’s it.  I hope it makes sense to you!

Make a lot of sense, thank you for the feedback and suggestions!)

> I encourage everyone to give it a spin, fearlessly!
> What I did was (roughly):
>
>   git clone https://git.sr.ht/~abcdw/rde
>   guix git authenticate \
>     "257cebd587b66e4d865b3537a9a88cccd7107c95" \
>     "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
>     -k origin/keyring

And to get the initial configuration, it's a good idea to take a look at
gnu/home/examples directory or call import action:

   ./pre-inst-env guix home import > /path/to/home-config.scm

>   ./pre-inst-env guix home reconfigure /path/to/home-config.scm

For people, who is not yet familiar with Guix Home, the project and
documentation web pages:

https://sr.ht/~abcdw/rde/
https://guix-home.trop.in/Home-Configuration.html#Home-Configuration

Re: Early feedback on Guix Home

[Ludovic Courtès]

Hi,

Andrew Tropin <andrew@trop.in> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> I found ‘symlink-manager.scm’, which is what I was looking for, but
>> that code is fairly complex.
>
> Yep, perhaps it a little monstous)  Maybe cleaning it up is a good idea
> before sending the patch to guix.

That’d be great.

>> Possible actions:
>>
>>   1. Provide a ‘guix home init’ command (or similar) that creates an
>>      initial Home config based on existing config.
>
> Xinglu implemented `guix home import`, which creates a simple
> home-environment configuration, which contains the same packages as ~/.guix-profile

Oh nice.  Currently it’s roughly equivalent to ‘guix package
--export-manifest’, which is a good start but it’d be interesting to see
if it can go beyond that.

>>   2. In some cases, such as OpenSSH, provide converters from the native
>>      format to its Scheme equivalent (maybe?).
>
> It's a good idea and Xinglu also mentioned it, but I find it to be a lot
> of extra work, so I propose to postpone it until next time, IMO it's
> better to focus on moving Guix Home from rde repo first in the current
> state and add new functionality after that step is done, otherwise we
> can stuck with wip-guix-home for months.

Agreed, I’m not saying this should be done before the merge.

>>   3. For each service, provide an escape hatch: a way for users to
>>      provide a raw config file.  We do that for all or most of the Guix
>>      System services, and it helps a lot when people are starting from
>>      an existing config.
>
> We do it as well, the only difference is that we try to utilize target
> program capabilities or slurp-file-gexp helper for that.
>
> The first one means that target configuration format allows to use some
> directive to load the content of another file:
> https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/ssh.scm#L190
> https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/emacs.scm#L200

Oh great.  Somehow I had overlooked these.

IWBN to have prominent examples of these in the manual—e.g., SSH
configuration that includes a hand-written .ssh/config file.

>> In terms of API, I noticed that in places such as
>> ‘home-bash-configuration’, config snippets are represented as a list of
>> strings (internally passed to ‘mixed-text-file’).  That forces users to
>> mix different languages in their .scm file—e.g., half of my Home config
>> is .bash{rc,_profile} snippets embedded in Scheme strings.  That’s
>> inconvenient.
>
> Can you elaborate on that please, ideally with some examples.

Currently I have this:

--8<---------------cut here---------------start------------->8---
   (service home-bash-service-type
            (home-bash-configuration
             (guix-defaults? #t)
             (bash-profile '("\

[...]

"))
             (bashrc '("

[...]

"))))
--8<---------------cut here---------------end--------------->8---

where I omitted ~30 lines of shell snippets embedded in Scheme strings.

It’d be more convenient if I could instead write:

  (home-bash-configuration
    (bash-profile (local-file "./bash_profile"))
    (bashrc (local-file "./bashrc")))

Thanks,
Ludo’.

Re: Early feedback on Guix Home

[Xinglu Chen]

[-- Attachment #1: Type: text/plain, Size: 5830 bytes --]

On Wed, Jun 23 2021, Ludovic Courtès wrote:

> Hello!
>
> As discussed on IRC a few days ago, I finally gave Guix Home a try and I
> like it!
>
> I thought I’d share my first impressions so we can try and address them
> in the process of getting it merged.
>
> First, I think one of the main reasons why it took me so long to try it
> out is that I was afraid of what would happen at “activation time” (upon
> reconfigure).  Were my dot files going to be deleted?  If so, which ones
> exactly should I back up?  That led me to look more closely at the code
> to better understand what was going to happen.  I found
> ‘symlink-manager.scm’, which is what I was looking for, but that code is
> fairly complex.
>
> Anyway, I backed up a bunch of files :-) and eventually gave it a try,
> just to notice that ‘guix home reconfigure’ was very careful about
> creating backups of any files it was going to overwrite, and it was also
> explicitly saying what it’s doing.  Perfect.

Yeah, the output is pretty verbose, which is good if someone is just
getting started with it, but there should probably also be an option to
make it less verbose.

> I see two possible improvements:
>
>   1. Make the manual very upfront about that: don’t be afraid, config
>      files are backed up at that location, etc.

Yeah, the manual needs some more work, maybe we should add an ‘migrating
to Guix Home’ section?

>   2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
>      easier to understand what’s going on.
>
> Second, the other thing that stopped me from getting started is the
> initial config.  How could I move from all my undisciplined dotfiles to
> the single explicit config?  Eventually, I found that starting with
> nothing but packages, ‘home-bash-service-type’, and
> ‘home-ssh-service-type’ was the most reasonable option to begin with.
>
> Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
> have a long ‘.ssh/config’ file and I wasn’t going to turn that into
> ‘ssh-host’ lines by hand.

There is a ‘home-generic-service’ procedure that allows one to install
packages in dump a file somewhere in their home directory.

  (home-generic-service
   'ssh-config
   #:packages (list openssh)
   #:files `(("ssh/config"
              ,(local-file "/path/to/some/ssh/config"))))

> Possible actions:
>
>   1. Provide a ‘guix home init’ command (or similar) that creates an
>      initial Home config based on existing config.

As Andrew mentioned, I recently added a ‘guix home import’ command, but
in only imports the installed user packages.  Creating configurations
for the packages would require a lot more work, unless we just read the
contents of ~/.bashrc and ~/.config/git/config and use
‘home-generic-service’ and ‘plain-file’, instead of using
‘home-bash-configuration’ and ‘home-git-configuration’.

>   2. In some cases, such as OpenSSH, provide converters from the native
>      format to its Scheme equivalent (maybe?).

That would require a lot of work; we would have to parse all sorts of
weird configuration formats, not to mention that the upstream
configuration format can change in the future.  It would be nice to
have, but I don’t think it should be a blocker for merging Guix Home.

>   3. For each service, provide an escape hatch: a way for users to
>      provide a raw config file.  We do that for all or most of the Guix
>      System services, and it helps a lot when people are starting from
>      an existing config.

Since we already have the ‘home-generic-service’ helper, I am not sure
if explicitly providing an escape hatch for every single service is
worth it.  I feel like the point is to use Scheme to configure things,
and not to just concatenate big opaque strings.  People who haven’t
re-written their configs in Scheme can always use
‘home-generic-service’.  ‘home-generic-service’ is also useful if say
the user wants to configure Mpv, but there is no Mpv service in Guix
Home.

> In terms of API, I noticed that in places such as
> ‘home-bash-configuration’, config snippets are represented as a list of
> strings (internally passed to ‘mixed-text-file’).  That forces users to
> mix different languages in their .scm file—e.g., half of my Home config
> is .bash{rc,_profile} snippets embedded in Scheme strings.  That’s
> inconvenient.
>
> Possible action:
>
>   1. Change config records to accept file-like objects instead of
>      strings.  That way, users can choose to have snippets inlined (in a
>      ‘plain-file’ object) or separate (via ‘local-file’).  See for
>      example how ‘tor-configuration->torrc’ does it.

Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
extenal file, but using existing APIs like ‘local-file’ is probably a
better idea.

> That’s it.  I hope it makes sense to you!

Thank you for the feedback!  Great to see that people are using and
enjoying Guix Home :)

> I encourage everyone to give it a spin, fearlessly!
> What I did was (roughly):
>
>   git clone https://git.sr.ht/~abcdw/rde
>   guix git authenticate \
>     "257cebd587b66e4d865b3537a9a88cccd7107c95" \
>     "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
>     -k origin/keyring
>   ./pre-inst-env guix home reconfigure /path/to/home-config.scm

Alternatively, one can also use it as a channel:

  (channel
    (name 'rde)
    (url "https://git.sr.ht/~abcdw/rde"))
    (introduction
     (make-channel-introduction
      "257cebd587b66e4d865b3537a9a88cccd7107c95"
      (openpgp-fingerprint
       "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0"))))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: Early feedback on Guix Home

[Andrew Tropin]

Xinglu Chen <public@yoctocell.xyz> writes:

> On Wed, Jun 23 2021, Ludovic Courtès wrote:
>
>> Hello!
>>
>> As discussed on IRC a few days ago, I finally gave Guix Home a try and I
>> like it!
>>
>> I thought I’d share my first impressions so we can try and address them
>> in the process of getting it merged.
>>
>> First, I think one of the main reasons why it took me so long to try it
>> out is that I was afraid of what would happen at “activation time” (upon
>> reconfigure).  Were my dot files going to be deleted?  If so, which ones
>> exactly should I back up?  That led me to look more closely at the code
>> to better understand what was going to happen.  I found
>> ‘symlink-manager.scm’, which is what I was looking for, but that code is
>> fairly complex.
>>
>> Anyway, I backed up a bunch of files :-) and eventually gave it a try,
>> just to notice that ‘guix home reconfigure’ was very careful about
>> creating backups of any files it was going to overwrite, and it was also
>> explicitly saying what it’s doing.  Perfect.
>
> Yeah, the output is pretty verbose, which is good if someone is just
> getting started with it, but there should probably also be an option to
> make it less verbose.
>
>> I see two possible improvements:
>>
>>   1. Make the manual very upfront about that: don’t be afraid, config
>>      files are backed up at that location, etc.
>
> Yeah, the manual needs some more work, maybe we should add an ‘migrating
> to Guix Home’ section?

Yup, on my todo list.

>>   2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
>>      easier to understand what’s going on.
>>
>> Second, the other thing that stopped me from getting started is the
>> initial config.  How could I move from all my undisciplined dotfiles to
>> the single explicit config?  Eventually, I found that starting with
>> nothing but packages, ‘home-bash-service-type’, and
>> ‘home-ssh-service-type’ was the most reasonable option to begin with.
>>
>> Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
>> have a long ‘.ssh/config’ file and I wasn’t going to turn that into
>> ‘ssh-host’ lines by hand.
>
> There is a ‘home-generic-service’ procedure that allows one to install
> packages in dump a file somewhere in their home directory.
>
>   (home-generic-service
>    'ssh-config
>    #:packages (list openssh)
>    #:files `(("ssh/config"
>               ,(local-file "/path/to/some/ssh/config"))))
>
>> Possible actions:
>>
>>   1. Provide a ‘guix home init’ command (or similar) that creates an
>>      initial Home config based on existing config.
>
> As Andrew mentioned, I recently added a ‘guix home import’ command, but
> in only imports the installed user packages.  Creating configurations
> for the packages would require a lot more work, unless we just read the
> contents of ~/.bashrc and ~/.config/git/config and use
> ‘home-generic-service’ and ‘plain-file’, instead of using
> ‘home-bash-configuration’ and ‘home-git-configuration’.
>
>>   2. In some cases, such as OpenSSH, provide converters from the native
>>      format to its Scheme equivalent (maybe?).
>
> That would require a lot of work; we would have to parse all sorts of
> weird configuration formats, not to mention that the upstream
> configuration format can change in the future.  It would be nice to
> have, but I don’t think it should be a blocker for merging Guix Home.
>
>>   3. For each service, provide an escape hatch: a way for users to
>>      provide a raw config file.  We do that for all or most of the Guix
>>      System services, and it helps a lot when people are starting from
>>      an existing config.
>
> Since we already have the ‘home-generic-service’ helper, I am not sure
> if explicitly providing an escape hatch for every single service is
> worth it.  I feel like the point is to use Scheme to configure things,
> and not to just concatenate big opaque strings.  People who haven’t
> re-written their configs in Scheme can always use
> ‘home-generic-service’.  ‘home-generic-service’ is also useful if say
> the user wants to configure Mpv, but there is no Mpv service in Guix
> Home.

In most cases we allows gexps or/and file-like objects (with
`local-file` and include/load or similar directive provided by target
software it's easy to include/source already existing file), so it's
almost always a way to take current plain-text file configuration and
include or slurp it into configuration home-service.  In other words,
there is already an escape hatch for almost every home-service.

>> In terms of API, I noticed that in places such as
>> ‘home-bash-configuration’, config snippets are represented as a list of
>> strings (internally passed to ‘mixed-text-file’).  That forces users to
>> mix different languages in their .scm file—e.g., half of my Home config
>> is .bash{rc,_profile} snippets embedded in Scheme strings.  That’s
>> inconvenient.
>>
>> Possible action:
>>
>>   1. Change config records to accept file-like objects instead of
>>      strings.  That way, users can choose to have snippets inlined (in a
>>      ‘plain-file’ object) or separate (via ‘local-file’).  See for
>>      example how ‘tor-configuration->torrc’ does it.
>
> Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
> extenal file, but using existing APIs like ‘local-file’ is probably a
> better idea.

`slurp-file-gexp` is a simple function, which returns a gexp, which
reads file from store and returns it's content (in most cases to be
added to mixed-text-file), it's expected that user will use it with
file-like object provided by local-file or any other way.  The final
configuration will look like:

`((key1 . value2)
  (key2 . (list of values))
  ,(slurp-file-gexp (local-file "./file/to/inline"))
  (key3 . value3))

It's done this way, because for many apps it's hard to provide a
separate field like in tor-configuration, because it's not clear where
this file should be added (at the end or at the beginning of the file or
inside special section).  To make a generic solution we do not provide a
separate field for file-like object, which contains "plain-text"
configuration, but allows to use one of two options above, which allows
to achieve the same, but provides more fleixbility and makes
configurations of home-services more consistent/uniform.

I'll try to write a guideline for defining home-services in the near
future and will try to explain all the patterns and best practices for
service configurations, after that will start adjusting currently
existing services to conform guideline (in case they do not yet).

>> That’s it.  I hope it makes sense to you!
>
> Thank you for the feedback!  Great to see that people are using and
> enjoying Guix Home :)
>
>> I encourage everyone to give it a spin, fearlessly!
>> What I did was (roughly):
>>
>>   git clone https://git.sr.ht/~abcdw/rde
>>   guix git authenticate \
>>     "257cebd587b66e4d865b3537a9a88cccd7107c95" \
>>     "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
>>     -k origin/keyring
>>   ./pre-inst-env guix home reconfigure /path/to/home-config.scm
>
> Alternatively, one can also use it as a channel:
>
>   (channel
>     (name 'rde)
>     (url "https://git.sr.ht/~abcdw/rde"))
>     (introduction
>      (make-channel-introduction
>       "257cebd587b66e4d865b3537a9a88cccd7107c95"
>       (openpgp-fingerprint
>        "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0"))))

Re: Early feedback on Guix Home

[Ludovic Courtès]

Hi,

Xinglu Chen <public@yoctocell.xyz> skribis:

> On Wed, Jun 23 2021, Ludovic Courtès wrote:

[...]

>> Anyway, I backed up a bunch of files :-) and eventually gave it a try,
>> just to notice that ‘guix home reconfigure’ was very careful about
>> creating backups of any files it was going to overwrite, and it was also
>> explicitly saying what it’s doing.  Perfect.
>
> Yeah, the output is pretty verbose, which is good if someone is just
> getting started with it, but there should probably also be an option to
> make it less verbose.

Yes.  Also, we’ll have to make sure it’s internationalized.

>> I see two possible improvements:
>>
>>   1. Make the manual very upfront about that: don’t be afraid, config
>>      files are backed up at that location, etc.
>
> Yeah, the manual needs some more work, maybe we should add an ‘migrating
> to Guix Home’ section?

That’s a good idea.

>>   2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
>>      easier to understand what’s going on.
>>
>> Second, the other thing that stopped me from getting started is the
>> initial config.  How could I move from all my undisciplined dotfiles to
>> the single explicit config?  Eventually, I found that starting with
>> nothing but packages, ‘home-bash-service-type’, and
>> ‘home-ssh-service-type’ was the most reasonable option to begin with.
>>
>> Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
>> have a long ‘.ssh/config’ file and I wasn’t going to turn that into
>> ‘ssh-host’ lines by hand.
>
> There is a ‘home-generic-service’ procedure that allows one to install
> packages in dump a file somewhere in their home directory.
>
>   (home-generic-service
>    'ssh-config
>    #:packages (list openssh)
>    #:files `(("ssh/config"
>               ,(local-file "/path/to/some/ssh/config"))))

Neat.

>> Possible actions:
>>
>>   1. Provide a ‘guix home init’ command (or similar) that creates an
>>      initial Home config based on existing config.
>
> As Andrew mentioned, I recently added a ‘guix home import’ command, but
> in only imports the installed user packages.  Creating configurations
> for the packages would require a lot more work, unless we just read the
> contents of ~/.bashrc and ~/.config/git/config and use
> ‘home-generic-service’ and ‘plain-file’, instead of using
> ‘home-bash-configuration’ and ‘home-git-configuration’.

For SSH, generating something like:

   (service home-ssh-service-type
            (home-ssh-configuration
             (toplevel-options
              `((include . ,(local-file "ssh.conf"))))))

should be doable.  But yeah, we’ll have to see on a case-by-case basis
what can be achieved.

>>   2. In some cases, such as OpenSSH, provide converters from the native
>>      format to its Scheme equivalent (maybe?).
>
> That would require a lot of work; we would have to parse all sorts of
> weird configuration formats, not to mention that the upstream
> configuration format can change in the future.  It would be nice to
> have, but I don’t think it should be a blocker for merging Guix Home.

Agreed.

>>   3. For each service, provide an escape hatch: a way for users to
>>      provide a raw config file.  We do that for all or most of the Guix
>>      System services, and it helps a lot when people are starting from
>>      an existing config.
>
> Since we already have the ‘home-generic-service’ helper, I am not sure
> if explicitly providing an escape hatch for every single service is
> worth it.  I feel like the point is to use Scheme to configure things,
> and not to just concatenate big opaque strings.  People who haven’t
> re-written their configs in Scheme can always use
> ‘home-generic-service’.  ‘home-generic-service’ is also useful if say
> the user wants to configure Mpv, but there is no Mpv service in Guix
> Home.

Yeah, ‘home-generic-service’ helps a lot, I didn’t know about it.

Overall, I think what I’m saying is that we should offer a smooth and
gradual transition for enthusiasts (like me!) who’re willing to switch
but can’t just be expected to rewrite all their config at once.

>> Possible action:
>>
>>   1. Change config records to accept file-like objects instead of
>>      strings.  That way, users can choose to have snippets inlined (in a
>>      ‘plain-file’ object) or separate (via ‘local-file’).  See for
>>      example how ‘tor-configuration->torrc’ does it.
>
> Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
> extenal file, but using existing APIs like ‘local-file’ is probably a
> better idea.

Yes, it feels more natural.  Also, ‘slurp-file-gexp’ returns a gexp (a
code snippet), but as a user you don’t know where that snippet is going
to be inserted; it may not work in some contexts.

Thanks!

Ludo’.

Re: Early feedback on Guix Home

[Andrew Tropin]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Xinglu Chen <public@yoctocell.xyz> skribis:
>
>> On Wed, Jun 23 2021, Ludovic Courtès wrote:
>
> [...]
>
>>> Anyway, I backed up a bunch of files :-) and eventually gave it a try,
>>> just to notice that ‘guix home reconfigure’ was very careful about
>>> creating backups of any files it was going to overwrite, and it was also
>>> explicitly saying what it’s doing.  Perfect.
>>
>> Yeah, the output is pretty verbose, which is good if someone is just
>> getting started with it, but there should probably also be an option to
>> make it less verbose.
>
> Yes.  Also, we’ll have to make sure it’s internationalized.
>
>>> I see two possible improvements:
>>>
>>>   1. Make the manual very upfront about that: don’t be afraid, config
>>>      files are backed up at that location, etc.
>>
>> Yeah, the manual needs some more work, maybe we should add an ‘migrating
>> to Guix Home’ section?
>
> That’s a good idea.
>
>>>   2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
>>>      easier to understand what’s going on.
>>>
>>> Second, the other thing that stopped me from getting started is the
>>> initial config.  How could I move from all my undisciplined dotfiles to
>>> the single explicit config?  Eventually, I found that starting with
>>> nothing but packages, ‘home-bash-service-type’, and
>>> ‘home-ssh-service-type’ was the most reasonable option to begin with.
>>>
>>> Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
>>> have a long ‘.ssh/config’ file and I wasn’t going to turn that into
>>> ‘ssh-host’ lines by hand.
>>
>> There is a ‘home-generic-service’ procedure that allows one to install
>> packages in dump a file somewhere in their home directory.
>>
>>   (home-generic-service
>>    'ssh-config
>>    #:packages (list openssh)
>>    #:files `(("ssh/config"
>>               ,(local-file "/path/to/some/ssh/config"))))
>
> Neat.
>
>>> Possible actions:
>>>
>>>   1. Provide a ‘guix home init’ command (or similar) that creates an
>>>      initial Home config based on existing config.
>>
>> As Andrew mentioned, I recently added a ‘guix home import’ command, but
>> in only imports the installed user packages.  Creating configurations
>> for the packages would require a lot more work, unless we just read the
>> contents of ~/.bashrc and ~/.config/git/config and use
>> ‘home-generic-service’ and ‘plain-file’, instead of using
>> ‘home-bash-configuration’ and ‘home-git-configuration’.
>
> For SSH, generating something like:
>
>    (service home-ssh-service-type
>             (home-ssh-configuration
>              (toplevel-options
>               `((include . ,(local-file "ssh.conf"))))))
>
> should be doable.  But yeah, we’ll have to see on a case-by-case basis
> what can be achieved.
>
>>>   2. In some cases, such as OpenSSH, provide converters from the native
>>>      format to its Scheme equivalent (maybe?).
>>
>> That would require a lot of work; we would have to parse all sorts of
>> weird configuration formats, not to mention that the upstream
>> configuration format can change in the future.  It would be nice to
>> have, but I don’t think it should be a blocker for merging Guix Home.
>
> Agreed.
>
>>>   3. For each service, provide an escape hatch: a way for users to
>>>      provide a raw config file.  We do that for all or most of the Guix
>>>      System services, and it helps a lot when people are starting from
>>>      an existing config.
>>
>> Since we already have the ‘home-generic-service’ helper, I am not sure
>> if explicitly providing an escape hatch for every single service is
>> worth it.  I feel like the point is to use Scheme to configure things,
>> and not to just concatenate big opaque strings.  People who haven’t
>> re-written their configs in Scheme can always use
>> ‘home-generic-service’.  ‘home-generic-service’ is also useful if say
>> the user wants to configure Mpv, but there is no Mpv service in Guix
>> Home.
>
> Yeah, ‘home-generic-service’ helps a lot, I didn’t know about it.

Will mention it in the manual.

> Overall, I think what I’m saying is that we should offer a smooth and
> gradual transition for enthusiasts (like me!) who’re willing to switch
> but can’t just be expected to rewrite all their config at once.
>
>>> Possible action:
>>>
>>>   1. Change config records to accept file-like objects instead of
>>>      strings.  That way, users can choose to have snippets inlined (in a
>>>      ‘plain-file’ object) or separate (via ‘local-file’).  See for
>>>      example how ‘tor-configuration->torrc’ does it.
>>
>> Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
>> extenal file, but using existing APIs like ‘local-file’ is probably a
>> better idea.
>
> Yes, it feels more natural.  Also, ‘slurp-file-gexp’ returns a gexp (a
> code snippet), but as a user you don’t know where that snippet is going
> to be inserted; it may not work in some contexts.

Acually, the idea behind `slurp-file-gexp` is that you always know where
it will be inserted, because it will be inside the specific section of
the configuration.  Take a look at emacs home-service example:
https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/emacs.scm#L91

I'll explain it in more details in the manual.

Correct me, if I missunderstood your point.

Re: Early feedback on Guix Home

[Ludovic Courtès]

Hi,

(Sorry for the late reply…)

Andrew Tropin <andrew@trop.in> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>>>> Possible action:
>>>>
>>>>   1. Change config records to accept file-like objects instead of
>>>>      strings.  That way, users can choose to have snippets inlined (in a
>>>>      ‘plain-file’ object) or separate (via ‘local-file’).  See for
>>>>      example how ‘tor-configuration->torrc’ does it.
>>>
>>> Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
>>> extenal file, but using existing APIs like ‘local-file’ is probably a
>>> better idea.
>>
>> Yes, it feels more natural.  Also, ‘slurp-file-gexp’ returns a gexp (a
>> code snippet), but as a user you don’t know where that snippet is going
>> to be inserted; it may not work in some contexts.
>
> Acually, the idea behind `slurp-file-gexp` is that you always know where
> it will be inserted, because it will be inside the specific section of
> the configuration.  Take a look at emacs home-service example:
> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/emacs.scm#L91

What I mean is that, in a general sense, one cannot know whether the
gexp will be inserted in a place where it’s “valid”.  Consider the
following examples, where the gexp is meant to be inserted in lieu of
“PLACEHOLDER”:

  #~(list '(#$PLACEHOLDER))  ;it’s quoted

  #~(let ((call-with-input-file (const #f)))
      #$PLACEHOLDER)

These are “hygiene” problems discussed in the “Code Staging in GNU Guix”
paper.

All this to say that, from an API viewpoint, I think it’s (1) more
robust, as I wrote, and (2) clearer to expect file-like objects in such
places.  It’s clearer because users can be expected to have an
understanding of what ‘local-file’ does, whereas ‘slurp-file-gexp’ is
more involved.

I hope this clarifies what I had in mind!

Ludo’.

Re: Early feedback on Guix Home

[Andrew Tropin]

[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> (Sorry for the late reply…)
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>>>> Possible action:
>>>>>
>>>>>   1. Change config records to accept file-like objects instead of
>>>>>      strings.  That way, users can choose to have snippets inlined (in a
>>>>>      ‘plain-file’ object) or separate (via ‘local-file’).  See for
>>>>>      example how ‘tor-configuration->torrc’ does it.
>>>>
>>>> Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
>>>> extenal file, but using existing APIs like ‘local-file’ is probably a
>>>> better idea.
>>>
>>> Yes, it feels more natural.  Also, ‘slurp-file-gexp’ returns a gexp (a
>>> code snippet), but as a user you don’t know where that snippet is going
>>> to be inserted; it may not work in some contexts.
>>
>> Acually, the idea behind `slurp-file-gexp` is that you always know where
>> it will be inserted, because it will be inside the specific section of
>> the configuration.  Take a look at emacs home-service example:
>> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/emacs.scm#L91
>
> What I mean is that, in a general sense, one cannot know whether the
> gexp will be inserted in a place where it’s “valid”.  Consider the
> following examples, where the gexp is meant to be inserted in lieu of
> “PLACEHOLDER”:
>
>   #~(list '(#$PLACEHOLDER))  ;it’s quoted
>
>   #~(let ((call-with-input-file (const #f)))
>       #$PLACEHOLDER)
>
> These are “hygiene” problems discussed in the “Code Staging in GNU Guix”
> paper.
>
> All this to say that, from an API viewpoint, I think it’s (1) more
> robust, as I wrote, and (2) clearer to expect file-like objects in such
> places.  It’s clearer because users can be expected to have an
> understanding of what ‘local-file’ does, whereas ‘slurp-file-gexp’ is
> more involved.
>
> I hope this clarifies what I had in mind!
>
> Ludo’.

Got the problem.  Will take a closer look, when will be preparing this
code for upstreaming and maybe will reconsider the approach or will rise
another discussion on that.  Also, need to schedule a reading of your
paper on gexps)

Thank you for clarification!)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: Early feedback on Guix Home

[Xinglu Chen]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Tue, Jun 29 2021, Ludovic Courtès wrote:

> Hi,
>
> Xinglu Chen <public@yoctocell.xyz> skribis:
>
>> On Wed, Jun 23 2021, Ludovic Courtès wrote:
>
> [...]
>
>>> Anyway, I backed up a bunch of files :-) and eventually gave it a try,
>>> just to notice that ‘guix home reconfigure’ was very careful about
>>> creating backups of any files it was going to overwrite, and it was also
>>> explicitly saying what it’s doing.  Perfect.
>>
>> Yeah, the output is pretty verbose, which is good if someone is just
>> getting started with it, but there should probably also be an option to
>> make it less verbose.
>
> Yes.  Also, we’ll have to make sure it’s internationalized.

How would we do that?  Would we use (G_ ...) or something?

>>> Possible actions:
>>>
>>>   1. Provide a ‘guix home init’ command (or similar) that creates an
>>>      initial Home config based on existing config.
>>
>> As Andrew mentioned, I recently added a ‘guix home import’ command, but
>> in only imports the installed user packages.  Creating configurations
>> for the packages would require a lot more work, unless we just read the
>> contents of ~/.bashrc and ~/.config/git/config and use
>> ‘home-generic-service’ and ‘plain-file’, instead of using
>> ‘home-bash-configuration’ and ‘home-git-configuration’.
>
> For SSH, generating something like:
>
>    (service home-ssh-service-type
>             (home-ssh-configuration
>              (toplevel-options
>               `((include . ,(local-file "ssh.conf"))))))
>
> should be doable.  But yeah, we’ll have to see on a case-by-case basis
> what can be achieved.

Yeah, I will look more into adding something like this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: Early feedback on Guix Home

[jbranso]

June 24, 2021 8:14 AM, "Xinglu Chen" <public@yoctocell.xyz> wrote:

> On Wed, Jun 23 2021, Ludovic Courtès wrote:
> 
> Alternatively, one can also use it as a channel:
> 
> (channel
> (name 'rde)
> (url "https://git.sr.ht/~abcdw/rde"))
> (introduction
> (make-channel-introduction
> "257cebd587b66e4d865b3537a9a88cccd7107c95"
> (openpgp-fingerprint
> "2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0"))))

Maybe I'm doing it wrong...my ~/.config/guix/channels.scm

;; Add variant packages to those Guix provides.
(append
(list
(channel
(name 'guix-packages)
(url "https://notabug.org/jbranso/guix-packages"))
(channel
(name 'rde)
(url "https://git.sr.ht/~abcdw/rde")
(introduction
(make-channel-introduction
"257cebd587b66e4d865b3537a9a88cccd7107c95"
(openpgp-fingerprint
"2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0")))))
%default-channels)

$ guix pull
Updating channel 'guix-packages' from Git repository at
'https://notabug.org/jbranso/guix-packages'...
Updating channel 'rde' from Git repository at 'https://git.sr.ht/~abcdw/rde'...
Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 8553f00 (3 new commits)...
Building from these channels:
guix https://git.savannah.gnu.org/git/guix.git 8553f00
rde https://git.sr.ht/~abcdw/rde 6d32c23
guix-packageshttps://notabug.org/jbranso/guix-packages d4b6f35

$ guix build home.scm
$ guix pull

I suppose for now I will use Ludo's suggestion:

  git clone https://git.sr.ht/~abcdw/rde
  guix git authenticate \
    "257cebd587b66e4d865b3537a9a88cccd7107c95" \
    "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
    -k origin/keyring
  ./pre-inst-env guix home reconfigure /path/to/home-config.scm

Failed to execute process './pre-inst-env'. Reason:
exec: Exec format error
The file './pre-inst-env' is marked as an executable but could not be run by the operating system.


Eventually I'll be able to get it to work!  But I do like the concept!

#+BEGIN_SRC scheme
(use-modules (gnu home)
	     (gnu home-services)
	     (gnu home-services ssh)
	     (gnu home-services shells)
	     (gnu home-services files)
	     (gnu services)
	     (gnu packages admin)
             (guix gexp)
             (my-home packages) ;; %defines %my-packages
             )


(home-environment
 (home-directory "/home/joshua")
 ;; (symlink-name ".guix-home-env")
 (packages %my-packages)
 (services
  (list
   (service home-bash-service-type
            (home-bash-configuration
             (guix-defaults? #t)
             (bash-profile '("\ export HISTFILE=$XDG_CACHE_HOME/.bash_history;\n"
                             "if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty3 ]]; then\n"
                             "# this may fix a bug that I have with termite confusing backspace as space in guix environment\n"
                             "# export TERM=linux\n"
                             "# shepherd -c /home/joshua/.config/shepherd/init.scm &\n"
                             "export MOZ_ENABLE_WAYLAND=1;\n"
                             "export GUIX_PACKAGE_PATH=/home/joshua/prog/gnu/guix/guix-packages/;\n"
                             "export XDG_DATA_DIRS=/var/lib/flatpak/exports/share:/home/joshua/.local/share/flatpak/exports/share:$XDG_DATA_DIRS;\n"
                             "exec dbus-run-session sway;\n"
                             "fi"
                             ))
             (bashrc
              '("alias lamora='ssh -p 63355 lamora'"))))

   (simple-service 'termite-config
                   home-files-service-type
                   (list `("config/termite/config"
                           ,(local-file "config-files/termite-config"
                                        "config"))))

   (simple-service 'sway-config
                   home-files-service-type
                   (list `("config/sway/config"
                           ,(local-file "config-files/sway-config"
                                        "config"))))

   (simple-service 'sway-config
                   home-files-service-type
                   (list `("config/sway/status.sh"
                           ,(local-file "config-files/sway-status.sh"
                                        "status.sh"))))
   
   )))

#+END_SRC

Re: Early feedback on Guix Home

[Andrew Tropin]

jbranso@dismail.de writes:

> June 24, 2021 8:14 AM, "Xinglu Chen" <public@yoctocell.xyz> wrote:
>
>> On Wed, Jun 23 2021, Ludovic Courtès wrote:
>> 
>> Alternatively, one can also use it as a channel:
>> 
>> (channel
>> (name 'rde)
>> (url "https://git.sr.ht/~abcdw/rde"))
>> (introduction
>> (make-channel-introduction
>> "257cebd587b66e4d865b3537a9a88cccd7107c95"
>> (openpgp-fingerprint
>> "2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0"))))
>
> Maybe I'm doing it wrong...my ~/.config/guix/channels.scm
>
> ;; Add variant packages to those Guix provides.
> (append
> (list
> (channel
> (name 'guix-packages)
> (url "https://notabug.org/jbranso/guix-packages"))
> (channel
> (name 'rde)
> (url "https://git.sr.ht/~abcdw/rde")
> (introduction
> (make-channel-introduction
> "257cebd587b66e4d865b3537a9a88cccd7107c95"
> (openpgp-fingerprint
> "2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0")))))
> %default-channels)
>
> $ guix pull
> Updating channel 'guix-packages' from Git repository at
> 'https://notabug.org/jbranso/guix-packages'...
> Updating channel 'rde' from Git repository at 'https://git.sr.ht/~abcdw/rde'...
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to 8553f00 (3 new commits)...
> Building from these channels:
> guix https://git.savannah.gnu.org/git/guix.git 8553f00
> rde https://git.sr.ht/~abcdw/rde 6d32c23
> guix-packageshttps://notabug.org/jbranso/guix-packages d4b6f35
>
> $ guix build home.scm

It should be `guix home build ./path/to/file.scm`.  Also, make sure that
before first run you've set proper GUILE_LOAD_PATH. (See
https://sr.ht/~abcdw/rde/ Guix Home section, Option 2).

It won't be needed, when Guix Home will be upstreamed, but for now it is
necessary, if you want to use it from rde channel.

> $ guix pull
>
> I suppose for now I will use Ludo's suggestion:
>
>   git clone https://git.sr.ht/~abcdw/rde
>   guix git authenticate \
>     "257cebd587b66e4d865b3537a9a88cccd7107c95" \
>     "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
>     -k origin/keyring
>   ./pre-inst-env guix home reconfigure /path/to/home-config.scm
>
> Failed to execute process './pre-inst-env'. Reason:
> exec: Exec format error
> The file './pre-inst-env' is marked as an executable but could not be run by the operating system.

It should work if you have a POSIX-compatible shell, but I also added
shebang to be sure that /bin/sh used.  Do git pull inside repository dir
and try again.  `./pre-inst-env guix home --help`

Let me know if it still fails.

>
> Eventually I'll be able to get it to work!  But I do like the concept!
>
> #+BEGIN_SRC scheme
> (use-modules (gnu home)
> 	     (gnu home-services)
> 	     (gnu home-services ssh)
> 	     (gnu home-services shells)
> 	     (gnu home-services files)
> 	     (gnu services)
> 	     (gnu packages admin)
>              (guix gexp)
>              (my-home packages) ;; %defines %my-packages
>              )
>
>
> (home-environment
>  (home-directory "/home/joshua")

home-directory, as well as symlink-name and symlink-path are now
depricated, I'll update the manual soon.

>  ;; (symlink-name ".guix-home-env")
>  (packages %my-packages)
>  (services
>   (list
>    (service home-bash-service-type
>             (home-bash-configuration
>              (guix-defaults? #t)
>              (bash-profile '("\ export HISTFILE=$XDG_CACHE_HOME/.bash_history;\n"
>                              "if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty3 ]]; then\n"
>                              "# this may fix a bug that I have with termite confusing backspace as space in guix environment\n"
>                              "# export TERM=linux\n"
>                              "# shepherd -c /home/joshua/.config/shepherd/init.scm &\n"
>                              "export MOZ_ENABLE_WAYLAND=1;\n"
>                              "export GUIX_PACKAGE_PATH=/home/joshua/prog/gnu/guix/guix-packages/;\n"
>                              "export XDG_DATA_DIRS=/var/lib/flatpak/exports/share:/home/joshua/.local/share/flatpak/exports/share:$XDG_DATA_DIRS;\n"
>                              "exec dbus-run-session sway;\n"
>                              "fi"
>                              ))
>              (bashrc
>               '("alias lamora='ssh -p 63355 lamora'"))))
>
>    (simple-service 'termite-config
>                    home-files-service-type
>                    (list `("config/termite/config"
>                            ,(local-file "config-files/termite-config"
>                                         "config"))))
>
>    (simple-service 'sway-config
>                    home-files-service-type
>                    (list `("config/sway/config"
>                            ,(local-file "config-files/sway-config"
>                                         "config"))))
>
>    (simple-service 'sway-config
>                    home-files-service-type
>                    (list `("config/sway/status.sh"
>                            ,(local-file "config-files/sway-status.sh"
>                                         "status.sh"))))
home-files-service-type accepts a list, so you do not need to create so
many service)
>    
>    )))
>
> #+END_SRC

Re: Early feedback on Guix Home

[Leo Prikler]

Am Donnerstag, den 24.06.2021, 20:42 +0300 schrieb Andrew Tropin:
> It should be `guix home build ./path/to/file.scm`.  Also, make sure
> that
> before first run you've set proper GUILE_LOAD_PATH. (See
> https://sr.ht/~abcdw/rde/ Guix Home section, Option 2).
> 
> It won't be needed, when Guix Home will be upstreamed, but for now it
> is
> necessary, if you want to use it from rde channel.
This probably comes a little late, but have you considered writing a
small wrapper module, that sets up %load-path and calls guix-home
proper?  The Guix package is set up to locate extensions from
share/guix/extensions.  I haven't checked if that works for channels,
but you ought to give it a try.

Regards,
Leo

Re: Early feedback on Guix Home

[Andrew Tropin]

Leo Prikler <leo.prikler@student.tugraz.at> writes:

> Am Donnerstag, den 24.06.2021, 20:42 +0300 schrieb Andrew Tropin:
>> It should be `guix home build ./path/to/file.scm`.  Also, make sure
>> that
>> before first run you've set proper GUILE_LOAD_PATH. (See
>> https://sr.ht/~abcdw/rde/ Guix Home section, Option 2).
>> 
>> It won't be needed, when Guix Home will be upstreamed, but for now it
>> is
>> necessary, if you want to use it from rde channel.
> This probably comes a little late, but have you considered writing a
> small wrapper module, that sets up %load-path and calls guix-home
> proper?  The Guix package is set up to locate extensions from
> share/guix/extensions.  I haven't checked if that works for channels,
> but you ought to give it a try.

IIRC, Jelle Licht proposed the usage of guix extensions some time ago,
but I decided not to provide such capability.

https://lists.sr.ht/~abcdw/rde-devel/patches/22245

But thank you for reminding, maybe I'll revisit guix extensions in the
future!)

Re: Early feedback on Guix Home

[Joshua Branson]

Andrew Tropin <andrew@trop.in> writes:

> jbranso@dismail.de writes:
>> $ guix pull
>>
>> I suppose for now I will use Ludo's suggestion:
>>
>>   git clone https://git.sr.ht/~abcdw/rde
>>   guix git authenticate \
>>     "257cebd587b66e4d865b3537a9a88cccd7107c95" \
>>     "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
>>     -k origin/keyring
>>   ./pre-inst-env guix home reconfigure /path/to/home-config.scm
>>
>> Failed to execute process './pre-inst-env'. Reason:
>> exec: Exec format error
>> The file './pre-inst-env' is marked as an executable but could not be run by the operating system.
>
> It should work if you have a POSIX-compatible shell, but I also added
> shebang to be sure that /bin/sh used.  Do git pull inside repository dir
> and try again.  `./pre-inst-env guix home --help`
>
> Let me know if it still fails.

Totally works now.  I was using the fish shell...and I don't believe
the fish shell is a POSIX compatible shell.  :) Works fine in bash.

Also thanks for the tips in my initial config!

And I really like the home-keyboard-service-type,
home-files-service-type, and home-state-service-type!  I've got a lot of
git repos.  It takes me forever to clone those.  Do you know if
home-state-service type will help me to automate something like

Git repo "programming" goes here:  /home/joshua/prog/

and git repo "cheatsheets" goes here: /home/joshua/prog/cheatsheets/

and git repo "guix-config" goes here: /home/joshua/prog/gnu/guix/guix-config/

and git repo "guix-src" goes here: /home/joshua/prog/gnu/guix/guix-src/

and git repo "guile" goes here: /home/joshua/prog/guile/

and git repr "gnucode.me" goes here: /home/joshua/prog/guile/gnucode.me


I don't that you are curious, but if you are my git repos are on
notabug.org/jbranso.

Thanks!  And thanks so much for working on this!  And thanks to Ludo for
testing it!

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Early feedback on Guix Home

[Andrew Tropin]

Joshua Branson <jbranso@dismail.de> writes:

> Andrew Tropin <andrew@trop.in> writes:
>
>> jbranso@dismail.de writes:
>>> $ guix pull
>>>
>>> I suppose for now I will use Ludo's suggestion:
>>>
>>>   git clone https://git.sr.ht/~abcdw/rde
>>>   guix git authenticate \
>>>     "257cebd587b66e4d865b3537a9a88cccd7107c95" \
>>>     "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
>>>     -k origin/keyring
>>>   ./pre-inst-env guix home reconfigure /path/to/home-config.scm
>>>
>>> Failed to execute process './pre-inst-env'. Reason:
>>> exec: Exec format error
>>> The file './pre-inst-env' is marked as an executable but could not be run by the operating system.
>>
>> It should work if you have a POSIX-compatible shell, but I also added
>> shebang to be sure that /bin/sh used.  Do git pull inside repository dir
>> and try again.  `./pre-inst-env guix home --help`
>>
>> Let me know if it still fails.
>
> Totally works now.  I was using the fish shell...and I don't believe
> the fish shell is a POSIX compatible shell.  :) Works fine in bash.
>
> Also thanks for the tips in my initial config!
>
> And I really like the home-keyboard-service-type,
> home-files-service-type, and home-state-service-type!

I do care about multi-input-method setups, so it is one of the earliest
home services, also in rde features I provide emacs-input-method
feature, which I find quite useful too:
https://git.sr.ht/~abcdw/rde/tree/262c7fb2db7454fdf4f67bbc53ec0c0306a8fbaf/item/rde/features/emacs.scm#L238

> I've got a lot of
> git repos.  It takes me forever to clone those.  Do you know if
> home-state-service type will help me to automate something like
>
> Git repo "programming" goes here:  /home/joshua/prog/
>
> and git repo "cheatsheets" goes here: /home/joshua/prog/cheatsheets/
>
> and git repo "guix-config" goes here: /home/joshua/prog/gnu/guix/guix-config/
>
> and git repo "guix-src" goes here: /home/joshua/prog/gnu/guix/guix-src/
>
> and git repo "guile" goes here: /home/joshua/prog/guile/
>
> and git repr "gnucode.me" goes here: /home/joshua/prog/guile/gnucode.me

Yes, home-state-service perfectly covers this use case, however I do not
recommend to use it, because probably I'll refactor it quite hard sooner
or later.  For now you can consider it to be in alpha state.  Usage
example is here:
https://git.sr.ht/~abcdw/rde/tree/262c7fb2db7454fdf4f67bbc53ec0c0306a8fbaf/item/rde/config.scm#L436

>
> I don't that you are curious, but if you are my git repos are on
> notabug.org/jbranso.

Probably I need to add Guix Home configs collection section to rde repo
README to make it easier for people to explore other's configurations)

> Thanks!  And thanks so much for working on this!  And thanks to Ludo for
> testing it!
>
> --
> Joshua Branson (joshuaBPMan in #guix)
> Sent from Emacs and Gnus
>   https://gnucode.me
>   https://video.hardlimit.com/accounts/joshua_branson/video-channels
>   https://propernaming.org
>   "You can have whatever you want, as long as you help
> enough other people get what they want." - Zig Ziglar

Re: Early feedback on Guix Home and a basic almost complete sway service

[Joshua Branson]

Thanks for the help in my home.scm file by the way!  I figured since you
guys are writing a sway service, I'd share with you my current code for
a sway service.  I think I've got the records type flushed out enough to
build the default sway config file, but I have not finished turning it
into a proper service.  Anyway, here's the code if you are interested:

https://notabug.org/jbranso/guix-config/src/master/sway-service.scm

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Early feedback on Guix Home and a basic almost complete sway service

[Andrew Tropin]

Joshua Branson <jbranso@dismail.de> writes:

> Thanks for the help in my home.scm file by the way!  I figured since you
> guys are writing a sway service, I'd share with you my current code for
> a sway service.  I think I've got the records type flushed out enough to
> build the default sway config file, but I have not finished turning it
> into a proper service.  Anyway, here's the code if you are interested:
>
> https://notabug.org/jbranso/guix-config/src/master/sway-service.scm

Very cool!  Checked the source code briefly, I'll add the link to your
implementation to the Guix Home's source code and will revisit it before
sending sway home-service patch to guix.