Re: Multiple profiles with Guix Home

[Andrew Tropin]

On 2022-05-03 20:34, Liliana Marie Prikler wrote:

> Am Dienstag, dem 03.05.2022 um 17:13 +0300 schrieb Andrew Tropin:
>> On 2021-10-03 12:50, Liliana Marie Prikler wrote:
>> 
>> > Hi Guix,
>> > 
>> > it's been a while since the discussion of whether or not to collect
>> > multiple profiles into a single directory [1].  This suggestion
>> > takes inspiration from that, but goes a vastly different route. 
>> > Instead of using environment variables to control Guix, it takes
>> > advantage of the recently added Guix Home, even if it is still a
>> > technical preview.
>> > 
>> > So, what's the proposition?  I suggest we modify home-profile-
>> > service-type (or add a new service) such that it takes a list of
>> > <home-profile> records instead of a list of packages.  This record
>> > would be defined as
>> > 
>> >   (define-record-type* <home-profile> home-profile
>> >     make-home-profile home-profile? this-home-profile
>> >     (location home-profile-location) ; string, e.g. $HOME/.guix-
>> > profile
>> >     (short-name home-profile-short-name) ; string or #f, if given
>> >                                          ; construct a symlink in
>> >                                          ; /var/guix/.../per-user/
>> >     (manifest %home-profile-manifest) ; <manifest> or #f
>> >     (packages home-profile-packages) ; list of <package> or #f
>> >                                      ; fallback for manifest
>> >     (enabled? home-profile-enabled?) ; boolean, default #t
>> >     [...])
>> > 
>> >   (define (home-profile-manifest home-profile)
>> >     (or (%home-profile-manifest home-profile)
>> >         (and=> (home-profile-packages home-profile) 
>> >                packages->manifest))))
>> > 
>> > On init/reconfigure, `guix home' creates/updates all home-profiles
>> > which have a home-profile-manifest that is not #f and links them to
>> > the appropriate locations.  It also creates a shell startup script
>> > that loads those profiles that are enabled?, even if they have no
>> > manifest (this can be used to e.g. declare a pull profile, which
>> > `guix home' can't manage).  
>> > 
>> > Some existing home services would need to be adapted towards this
>> > multiple profile usage.  For instance, home-fontconfig-service-type
>> > would need to accept a list of directories, rather than hardcode
>> > its value.
>> > 
>> > What do y'all think?
>> > 
>> > <
>> > https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html
>> > >
>> > 
>> > 
>> 
>> It seems doable, but not sure about costs and benifits.
> Glad I have your attention now :)
>
> Depending on your use the time spent building `guix home' could go up
> or down.  If you simply add more profiles to it, that'll be an increase
> in cost, same if you don't make use of the feature at all due to the
> time spent field sanitizing.  If you do split your home in multiple
> profiles however, you will benefit from faster union builds, which
> themselves have quadratic complexity as a lower bound.
>

Yep, I already face some relatively long builds of profiles, I don't
remember when I started to face it, but splitting into a few independent
profile can make the situation better, need to experiment with it.

>> Also, cross-profile package installation can be error-prone, for
>> example if user install an emacs in main profile and emacs packages
>> in emacsy profile we will end up in a situation, where those emacs
>> package aren't available in Emacs.  Probably some other issues will
>> become clearer during implementation.
> The solution to that would be evaluating the search paths over all
> enabled packages.

It won't work if we have "managed outside" profiles and overall seems
quite fragile.

> However, I do think it's fine to do as we did before
> for now; people are already used to this aspect of Guix, but the fact
> that they need to code up their own shell wrappers to manage multiple
> profiles is not good optics imo.

Sounds reasonable.

>> Another idea I have in mind is to make such profiles (including guix
>> home's main profile) detached from ~/.config/guix/current.  For
>> example by providing channels specification as a part of <home-
>> profile>.  It will make it possible to freeze a costly-to-rebuild
>> profile at a given channels revisions and not to rebuild it, when the
>> main profile and channels for it get updated.
> I don't think that's meaningful.  For one, time-machine exists, for the
> other you can directly use inferiors in code.  With profiles managed by
> Guix Home, you could even make it so that said inferiors are "globally"
> managed.  I don't think a manifest consisting of inferior packages only
> would require rebuilding.  

I had some issues with inferiors previously, but will see, maybe it will
work for me.

> Another dirty hack would be to have the manifest evaluate to #f when
> you don't want to update it – as per my specification it will in that
> case be assumed that you're manually managing it.  Then all you need to
> control when to build it is a smart binding of environment variables.

Sounds hacky :)  Better to utilize inferiors here IMO.

I'm not sure when I get a spare time to experiment with this feature,
but I'll let you know.  In case you would draft an implemntation before
that, please share, I'll test it out and we can further discuss it.

-- 
Best regards,
Andrew Tropin

signature.asc
Description: PGP signature