Re: Multiple profiles with Guix Home

[Andrew Tropin <andrewtropin@gmail.com>]

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

On 2022-05-23 19:05, Liliana Marie Prikler wrote:

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

Looks ok for me.

>> 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?
>

This service is intended for profiles managed by Guix Home, so every
profile MUST be a part of home-environment (~/.guix-home is a symlink to
it).  I don't see any meaningful reasons to make it possible to
customize the path inside home-environment.

If you want to have profiles like ~/work/my-project/guix-profile or
~/.guix/profiles/my-python-environment managed by Guix Home you can
implement home-external-profiles-service-type, which can extended
activation service or any other impure tricks, but I would advice
against it.  I suggest either manage a profile with
home-[additional-]-profiles or manage them externally and load with
home-profile-paths/home-profile-loader.

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

This one looks simplier and also independent from #1, so I would
recommend to start with it.  Also, it's very likely that
home-profiles-service-type will be extending
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.

The migration should be quite simple here.

JFYI: The design of Guix Home is flexible, essential services can be
completely customized, even symlink-manager can be removed or
substituted with something else (for example to make a read-only home
workflow proposed by Julien Lepiller in guix-home-manager).  This is
also used in rde to substitute home-shell-profile-service-type with
alternative implementation:
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features.scm#L234

This way you can experiment with multi-profile approach even without
modifying existing code.

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

I also advice to treat it as an experiment.  IMO Guix Home should be
relatively conservative, stable and simple.  Other advanced workflows
in most cases should be implemented and maintained separately and be
optionally pluggable in Guix Home by overriding essential services or
any other way.  In cases such workflows demonstrates their benifits
without compromising simplicity, they can be included.

-- 
Best regards,
Andrew Tropin

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