Guix days guix home discussion

Guix days guix home discussion

[Gábor Boskovits]

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

On guix days in the guix home discussion the following observations were
made:
1. It is rare that guix home import does the right thing (it is usually
removing some startup file customizations, does not seem to arrange to pick
up profiles, not even its own). Either we should improve it, or document
that it only gives a skeleton configuration and add some guidance on the
steps needed to get a working one.
2. The user default profile and the home package profile being separate is
causing some issues. It might be enough to document all the special
profiles somewhere (which as of now include at least system profile, user
profile, pull profile and home profile), but we can also think about a bit
more general solution, along the lines of a home service that ensures that
a given profile matches the supplied manifest, and have variables for the
special profiles. (These could then provide extensions to the shell
services which could arrange to pick them up)
3. Sometime on home reconfigure the shell prompt customizations seem to get
lost. Sourcing the shell startup file fixes it. I will have to look into
this more to file a proper bug report.
4. Creating a guix development environment service would be beneficial, to
showcase the possibilities and to simplify onboarding. On top of there
could be an additional service that adds emacs integration to this
development environment.
5. There was a recommendation to relax the expectations on the home
services merged. Right now a lot of people are just writing services for
private use. Most probably such a single usecase service would already be
beneficial to multiple people. The idea is the following: make it easy for
an initial home service to be merged. (Example: do not ask to implement
options that the submitter is not using). Then take care that if there is
an addition to the service that it really gets merged with what we already
have. This needs a bit of up front design, we have to make sure that the
services can be extended while maintaining backwards compatibility.

[-- Attachment #2: Type: text/html, Size: 2169 bytes --]

Re: Guix days guix home discussion

[Efraim Flashner]

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

On Thu, Feb 29, 2024 at 12:59:53AM +0100, Gábor Boskovits wrote:
> On guix days in the guix home discussion the following observations were
> made:
> 1. It is rare that guix home import does the right thing (it is usually
> removing some startup file customizations, does not seem to arrange to pick
> up profiles, not even its own). Either we should improve it, or document
> that it only gives a skeleton configuration and add some guidance on the
> steps needed to get a working one.
> 2. The user default profile and the home package profile being separate is
> causing some issues. It might be enough to document all the special
> profiles somewhere (which as of now include at least system profile, user
> profile, pull profile and home profile), but we can also think about a bit
> more general solution, along the lines of a home service that ensures that
> a given profile matches the supplied manifest, and have variables for the
> special profiles. (These could then provide extensions to the shell
> services which could arrange to pick them up)

In the past we had some issues with various assumptions in guix that
~/.guix-profile was the main profile and we had to add additional
use-cases for ~/.guix-home. I'm not sure if we've gotten all of them
yet.

It also might be helpful to consider something along the lines of
exposing the symlink service bits from the home service modules and see
if it would be a good idea to offer adding a symlink from
~/.guix-home/profile to ~/.guix-profile.  Or (magically) adjusting
~/.guix-profile/etc/profile to also source ~/.guix-home/profile if it
exists.

> 3. Sometime on home reconfigure the shell prompt customizations seem to get
> lost. Sourcing the shell startup file fixes it. I will have to look into
> this more to file a proper bug report.
> 4. Creating a guix development environment service would be beneficial, to
> showcase the possibilities and to simplify onboarding. On top of there
> could be an additional service that adds emacs integration to this
> development environment.

Also on the topic of onboarding to guix-home, the etc-skel service now
also includes a bare-bones guix-home file.  It lives in
/etc/skel/guix-home-config.scm on Guix System.

> 5. There was a recommendation to relax the expectations on the home
> services merged. Right now a lot of people are just writing services for
> private use. Most probably such a single usecase service would already be
> beneficial to multiple people. The idea is the following: make it easy for
> an initial home service to be merged. (Example: do not ask to implement
> options that the submitter is not using). Then take care that if there is
> an addition to the service that it really gets merged with what we already
> have. This needs a bit of up front design, we have to make sure that the
> services can be extended while maintaining backwards compatibility.

Seeing how often we add an extra-config field for just about every other
service I don't think that should be a hindrance.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: Guix days guix home discussion

[Ludovic Courtès]

Hi!

Gábor Boskovits <gboskovits@gmail.com> skribis:

> 1. It is rare that guix home import does the right thing (it is usually
> removing some startup file customizations, does not seem to arrange to pick
> up profiles, not even its own). Either we should improve it, or document
> that it only gives a skeleton configuration and add some guidance on the
> steps needed to get a working one.

‘guix home import’ does exactly that: generate a first configuration
that you may find necessary to tweak.  Perhaps the manual should clarify
that?

I’m not sure what you mean though when you say it rarely does the right
thing.  Did you discuss examples?

> 2. The user default profile and the home package profile being separate is
> causing some issues. It might be enough to document all the special
> profiles somewhere (which as of now include at least system profile, user
> profile, pull profile and home profile), but we can also think about a bit
> more general solution, along the lines of a home service that ensures that
> a given profile matches the supplied manifest, and have variables for the
> special profiles. (These could then provide extensions to the shell
> services which could arrange to pick them up)

Likewise, would be nice to see if there are specific examples of
problems that people stumble upon.

> 3. Sometime on home reconfigure the shell prompt customizations seem to get
> lost. Sourcing the shell startup file fixes it. I will have to look into
> this more to file a proper bug report.
> 4. Creating a guix development environment service would be beneficial, to
> showcase the possibilities and to simplify onboarding. On top of there
> could be an additional service that adds emacs integration to this
> development environment.

Interesting, I like that.

(A colleague of mine has been working on a pre-configured Emacs
targeting developers using Guix and writing C/C++/Fortran and LaTeX:
<https://elementaryx.gitlabpages.inria.fr/>.)

> 5. There was a recommendation to relax the expectations on the home
> services merged. Right now a lot of people are just writing services for
> private use. Most probably such a single usecase service would already be
> beneficial to multiple people. The idea is the following: make it easy for
> an initial home service to be merged. (Example: do not ask to implement
> options that the submitter is not using). Then take care that if there is
> an addition to the service that it really gets merged with what we already
> have. This needs a bit of up front design, we have to make sure that the
> services can be extended while maintaining backwards compatibility.

I personally try to lower the barrier for Home services, but I think few
people (if any) beyond me review Home services.

We should expand the ‘home’ team; who’s in?

Thanks for the feedback,
Ludo’.

Re: Guix days guix home discussion

[Ryan Prior]

On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> I personally try to lower the barrier for Home services, but I think few
> people (if any) beyond me review Home services.
> 
> We should expand the ‘home’ team; who’s in?

I would like to contribute to Guix home, but haven't been able to get much use out of it myself. This is a combination of two frustrations I've hit:

1. I haven't been able to use Guix Home to migrate my home config across machines. I've done this 3 times since I started using Guix on what I would consider advanced-level (writing Guile, defining my own packages & manifests, contributing patches.) Each time, I've got frustrated with the applicability of what documentation or examples I could find, and ended up migrating the bad old way by copying config files & modifying them as needed. Guix does help me in these migrations somewhat by allowing me to install needed software environments in a non-disruptive way, but I haven't gotten any use out of Home here. For reference, my attempts have been on elementary OS and Ubuntu, never on Guix System.

2. I've desired to use Guix Home on foreign distros to run Guix services (like Docker or Postgres) via Shepherd, but have failed to do so thus far. I read documentation in Guix and Shepherd, and some source code. I've got Shepherd installed & running on some of my machines, but I can't figure out how to use it to run Guix services. Possibly I'm missing something, but I also wonder whether perhaps Guix services are only intended to run on Guix System?

I would like to help make Guix Home & services have an excellent experience on foreign distros. I intend to write documentation, blog posts and code to do so. I've been stuck, though, in actually making progress understanding how to accomplish my aims, and every time I've tried it so far I've been in enough of a hurry that I gave up after a couple days' hacking. If anybody wants to pair with me or lend a hand I'd be thrilled to get back to this.

Ryan

Re: Guix days guix home discussion

[Ludovic Courtès]

Hello!

Ryan Prior <rprior@protonmail.com> skribis:

> 1. I haven't been able to use Guix Home to migrate my home config across machines. I've done this 3 times since I started using Guix on what I would consider advanced-level (writing Guile, defining my own packages & manifests, contributing patches.) Each time, I've got frustrated with the applicability of what documentation or examples I could find, and ended up migrating the bad old way by copying config files & modifying them as needed. Guix does help me in these migrations somewhat by allowing me to install needed software environments in a non-disruptive way, but I haven't gotten any use out of Home here. For reference, my attempts have been on elementary OS and Ubuntu, never on Guix System.

If this is a documentation issue, it would be nice to pinpoint what
examples were missing or what info was unclear.

If it’s a more general applicability issue (like: “this thing is useless
to me”), then maybe that’s okay :-), or maybe we should look which or
your use cases should be addressed by Home but aren’t.

> 2. I've desired to use Guix Home on foreign distros to run Guix services (like Docker or Postgres) via Shepherd, but have failed to do so thus far. I read documentation in Guix and Shepherd, and some source code. I've got Shepherd installed & running on some of my machines, but I can't figure out how to use it to run Guix services. Possibly I'm missing something, but I also wonder whether perhaps Guix services are only intended to run on Guix System?

In general, you can only use services that are explicitly designed for
or “ported” to Guix Home, which are documented here:

  https://guix.gnu.org/manual/devel/en/html_node/Home-Services.html

(You can find them with ‘guix home search’.)

Now, there’s a mechanism in place that simplifies porting System
services to Home, though again, that work has to be done explicitly.

> I would like to help make Guix Home & services have an excellent experience on foreign distros. I intend to write documentation, blog posts and code to do so. I've been stuck, though, in actually making progress understanding how to accomplish my aims, and every time I've tried it so far I've been in enough of a hurry that I gave up after a couple days' hacking. If anybody wants to pair with me or lend a hand I'd be thrilled to get back to this.

Would be great!

Thanks,
Ludo’.

Re: Guix days guix home discussion

[Ryan Prior]

On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> ‘guix home import’ does exactly that: generate a first configuration
> that you may find necessary to tweak. Perhaps the manual should clarify
> that?

Maybe we should call it "guix home init" then? Describing it as "import" implies to me that a situation where relevant config is not imported would be seen as a bug, or at least as a potential site for improvement.

Re: Guix days guix home discussion

[Ludovic Courtès]

Ryan Prior <rprior@protonmail.com> skribis:

> On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> ‘guix home import’ does exactly that: generate a first configuration
>> that you may find necessary to tweak. Perhaps the manual should clarify
>> that?
>
> Maybe we should call it "guix home init" then? Describing it as "import" implies to me that a situation where relevant config is not imported would be seen as a bug, or at least as a potential site for improvement.

Yes, maybe, though it would be very different from ‘guix system init’,
which could be a source of confusion.

It would also be nice for it to recognize more config files, but it
doesn’t have to cover “everything” IMO.

Ludo’.