Re: Multiple profiles with Guix Home

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Donnerstag, dem 05.05.2022 um 19:07 +0200 schrieb Maxime Devos:
> Hi,
> 
> Previously, you wrote that people need to write shell wrappers.
> 
> > > [ cross-profile installation things ]
> > 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_.
> 
> (emphasis mine)  However, now you write that the mechanism already
> exists, all the user needs to do is "source .../etc/profile.sh",
> without any shell wrappers.
For the record, you don't _need_ to source any of those profiles by
hand.  You can choose to if you so desire, same as with every other
profile.  enabled? #f provides a way to specify that this is what you
desire.  Further, this is not management.  The profiles are still built
and updated using Guix Home -- unless you don't specify any manifest,
in which case they aren't.  The only degenerate case here would be
specifying both enabled? #f and no manifest.

> Am Donnerstag, dem 05.05.2022 um 13:05 +0200 schrieb Maxime Devos:
> > > Liliana Marie Prikler schreef op zo 03-10-2021 om 12:50 [+0200]:
> > > > 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).  
> > > 
> > > I assume there will be some mechanism to load disabled profiles
> > > (otherwise the disabled profiles seem a bit pointless to me, why
> > > not remove them with #; and avoid some build time)?
> > This mechanism already exists, it's source
> > /path/to/profile/etc/profile.sh.
> 
> But IIUC, "source .../etc/profile.sh" is not sufficient because of
> the search paths issue, so people need shell wrappers to make sure
> all search paths are set?  This seems contradictory to me.  Or am I
> mistaken on which shell wrappers you were referring to?
My assumption here is that the split profiles are still "complete",
hence thematic profiles.  A thematic profile could for instance consist
of all your emacs packages, in which case only emacs packages are added
into the union-build and only EMACSLOADPATH needs to be considered. 
Another thematic profile could consist of all the guile packages you
need always, e.g. guile-readline and guile-colorized, though both are
already in the system.  A third thematic profile could be all your
python, r, ..., packages, which you absolutely, no questions asked,
need to have sourced always.  And obviously, the big thematic profile
that still has a huge union-build despite all your efforts of splitting
your home profile neatly is the entirety of the NPM ecosystem :)