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>
