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 > records instead of a list of packages. This record would be defined as > > (define-record-type* 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) ; or #f > (packages home-profile-packages) ; list of 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? > > > > 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. 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))) 3. Maybe migrate ~/.guix-home/profile to ~/.guix-home/profiles/default. 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 Also, I can see potential complication of Guix Home in general due to multiple profiles capabilities and I still not sure that it worth the benefits mentioned below: I agree that multiple profiles can be benifitial for both better package organization/structuring needs and faster build/reconfigure times. I also see some demand from people requesting such a feature. 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. -- Best regards, Andrew Tropin