Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

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.

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

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

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.

Cheers