Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Dienstag, dem 03.05.2022 um 21:13 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op di 03-05-2022 om 20:34 [+0200]:
> > > 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,
> 
> They shouldn't have to be.  If there's a problem in the past that
> doesn't mean that it isn't a problem in the present anymore.  Also,
> while I'm aware of this problem, it's only due to having looked at
> some Guix code, I don't mix profiles so I wouldn't have seen this
> problem otherwise.  But if I didn't know the internals, started using
> Guix Home and saw some recommendation to split profiles, then I could
> end up with inscrutenable errors.
That's why I say the long-term goal is evaluating search paths over
multiple profiles.  However, given that Guix Home is currently a
technological preview and given on top that multiple profile support is
"write your own shell script, will ya?", I think we can leave that as a
nice to have for later.

> > but the fact that they need to code up their own shell wrappers to
> > manage multiple profiles is not good optics imo.
> 
> They don't have to code up shell wrappers or split profiles.  They
> can just use a single profile.
This sentence signals to me that you didn't think about this mail at
all.  Consider that people may want to split their packages across
small thematic profiles, but the current implementation of Guix hinders
them in doing so.

> > [...].  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.
> 
> Instead of working around quadratic behaviour, could we just make it
> linear behaviour?  
If you're really clever, you might find a way to get O(n log n) through
sorting.  In fact, looking closer at union-build, it seems to already
use hash tables, which would make much of the implementation O(n log
n), but that's a very naive analysis at a time in which I shouldn't do
too much complexity analysis.  Needless to say, you can't get better
than sorting.

> Also, why would the user need to split things, couldn't Guix do that
> automatically?
Oh, sure, I'll just train a machine learning model to partition
packages into profiles.  This will obviously be better than a human
figuring things out, because machines can't fail ever.

In case the above wasn't clear enough, I'd rather leave this decision
to the user along with the decision of whether or not to waste
electricity in training an artificial intelligence.  Offering a
declarative interface to profile splitting benefits everyone here.

Cheers