all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Guix days guix home discussion
@ 2024-02-28 23:59 Gábor Boskovits
  2024-02-29  7:23 ` Efraim Flashner
  2024-03-17 17:24 ` Ludovic Courtès
  0 siblings, 2 replies; 7+ messages in thread
From: Gábor Boskovits @ 2024-02-28 23:59 UTC (permalink / raw)
  To: Guix Devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guix days guix home discussion
  2024-02-28 23:59 Guix days guix home discussion Gábor Boskovits
@ 2024-02-29  7:23 ` Efraim Flashner
  2024-03-17 17:24 ` Ludovic Courtès
  1 sibling, 0 replies; 7+ messages in thread
From: Efraim Flashner @ 2024-02-29  7:23 UTC (permalink / raw)
  To: Gábor Boskovits; +Cc: Guix Devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guix days guix home discussion
  2024-02-28 23:59 Guix days guix home discussion Gábor Boskovits
  2024-02-29  7:23 ` Efraim Flashner
@ 2024-03-17 17:24 ` Ludovic Courtès
  2024-03-17 17:51   ` Ryan Prior
  2024-03-17 17:53   ` Ryan Prior
  1 sibling, 2 replies; 7+ messages in thread
From: Ludovic Courtès @ 2024-03-17 17:24 UTC (permalink / raw)
  To: Gábor Boskovits; +Cc: Guix Devel

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’.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guix days guix home discussion
  2024-03-17 17:24 ` Ludovic Courtès
@ 2024-03-17 17:51   ` Ryan Prior
  2024-03-17 21:18     ` Ludovic Courtès
  2024-03-17 17:53   ` Ryan Prior
  1 sibling, 1 reply; 7+ messages in thread
From: Ryan Prior @ 2024-03-17 17:51 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Gábor Boskovits, Guix Devel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guix days guix home discussion
  2024-03-17 17:24 ` Ludovic Courtès
  2024-03-17 17:51   ` Ryan Prior
@ 2024-03-17 17:53   ` Ryan Prior
  2024-03-17 21:20     ` Ludovic Courtès
  1 sibling, 1 reply; 7+ messages in thread
From: Ryan Prior @ 2024-03-17 17:53 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Gábor Boskovits, Guix Devel

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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guix days guix home discussion
  2024-03-17 17:51   ` Ryan Prior
@ 2024-03-17 21:18     ` Ludovic Courtès
  0 siblings, 0 replies; 7+ messages in thread
From: Ludovic Courtès @ 2024-03-17 21:18 UTC (permalink / raw)
  To: Ryan Prior; +Cc: Gábor Boskovits, Guix Devel

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’.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guix days guix home discussion
  2024-03-17 17:53   ` Ryan Prior
@ 2024-03-17 21:20     ` Ludovic Courtès
  0 siblings, 0 replies; 7+ messages in thread
From: Ludovic Courtès @ 2024-03-17 21:20 UTC (permalink / raw)
  To: Ryan Prior; +Cc: Gábor Boskovits, Guix Devel

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’.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-03-17 21:20 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-28 23:59 Guix days guix home discussion Gábor Boskovits
2024-02-29  7:23 ` Efraim Flashner
2024-03-17 17:24 ` Ludovic Courtès
2024-03-17 17:51   ` Ryan Prior
2024-03-17 21:18     ` Ludovic Courtès
2024-03-17 17:53   ` Ryan Prior
2024-03-17 21:20     ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.