Re: Multiple profiles with Guix Home

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Montag, dem 23.05.2022 um 16:14 +0300 schrieb Andrew Tropin:
> The discussion seems too heated and bloated, it's hard to reasonably
> address arguments mentioned around, so I'll just post some thoughts
> and a possible way to somehow proceed.
> 
> I suggest to split the bigger idea into smaller pieces, play with the
> implementation locally/in fork/branch and see how it goes:
> 
> 1. home-profiles-paths-service-type.  It will allow to add code for
> sourcing profiles in setup-environment script and thus implement
> workflows with multiple profiles.  Such profiles can be managed
> externally or in the future built as a part of home environment.
How about home-profile-loader-service-type as a name instead?  That
would imply that it's purpose is to load profiles.

> 2. home-[additional-]profiles-service-type.  It will allow to build
> profiles from list of packages, optionally add a profile to
> home-profiles-paths.  It will make ~/.guix-
> home/profiles/{emacs,web,etc}
> 
> To make it possible for other service to utilize multiple profiles,
> this service will be extandable with values like that:
> 
> `((default . ,(list curl wget))
>   (web . ,(list browser-ad-block-plugin))
>   (emacs . ,(list emacs emacs-cider emacs-modus-themes)))
I don't think I agree with this choice.  To satisfy both my own use
case of serving profiles in different locations from another and
another issue being raised w.r.t. configuring the location of the
.guix-home profile, I think we should make a triple of location,
optional short name, and manifest (which may be generated from packages
implicitly).  WDYT?

> 3. Maybe migrate ~/.guix-home/profile to ~/.guix-
> home/profiles/default.
Kinda agree, but with the caveat in (2).  Uniformity or chaos should be
a user choice :)

> I still can see a lot of potential problems related to search paths,
> however part of them can be solved by duplicating packages in
> different profiles or using dummy packages like emacs-consumer:
> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/packages/emacs.scm#L56
Or by making search paths first class in manifests, as also discussed
elsewhere.

> [...]
> Liliana, if you still into it, I suggest to start with something
> similiar to what I described above, share the draft implementation
> and intermediate results/impression in a separate thread and continue
> the further discussion.
Considering the above, I think a rough roadmap would be:
1. Implementing home-profiles-service-type (to build the profiles)
2. Implementing home-profile-loader-service-type
3. ???
4. Deprecate the existing home-profile-service-type in favor of the new
profile service type pair and/or implement it in terms of it.
where (1) and (2) could be done by two people/teams in parallel.

Given that the task has been simplified, I think I might start coding
on it, but I can't promise any particular deadline.  At the moment,
both my day job and review work delay any other contributions towards
Guix.

Cheers