Re: Multiple profiles with Guix Home

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

Am Donnerstag, dem 05.05.2022 um 22:13 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 21:08 [+0200]:
> > And you're not taking into account my time cost of debating you
> > when I already have manifests split across many files that I want
> > to manage as separate profiles using Guix Home, kthxbye.
> 
> Debating things is a one-time cost, whereas potential time
> savings/time increases will be a gain for all future users / a loss
> for all future users.  Also, didn't you ask for comments on your
> proposal, implicitely by sending to guix-devel@ and explicitly by
> 
> > What do y'all think?
> 
> ?
I did, but I assumed that people are already aware of multiple profile
workflows and the pains associated with them.  Having to debate the
semantics of a 2.5 year old blog posts should not be necessary in any
of these steps.  This is an initiative for enthusiastic users who want
to split their profiles, not a trick to convince them of doing things
outside their comfort zone.  The aforementioned sanitization overhead
when using the old configuration should be comparatively small,
otherwise we need to debate field sanitizers.

> > But to entertain the idea, suppose Alice wants to make her profiles
> > smaller so that they build faster.  Which sounds more reasonable? 
> > Bundling groups of packages that fit together into their own
> > manifests, then instantiating one profile for each, or rolling a
> > six-sided die and putting the package into whichever bin is number
> > four?  If you're a machine, you probably think the latter.  
> 
> Seems like a false dichotomy, why not: Alice teaches Guix to do the
> equivalent of rolling a six-sided dice, so she doesn't have to figure
> out a bundling and she doesn't have to manually roll dices.  Now,
> teaching this is a bit of a time investment, but she shares it with
> all other Guix users, so everyone benefits of automatically better
> performance.
You are aware that by rolling a six-sided die I did include "clever"
applications of rand, are you?  Even so, your profile splitting won't
go anywhere if you don't have a data representation of what a split
profile actually looks like.  Which sounds a lot like "I want the
benefits of your system, but I don't want the user to profit from them
by making an explicit choice on their own".  If that's your take, I
have to hard disagree.

> > What could be more fair than a six-sided die?  Why, a seven-sided
> > die of course!
> 
> I assume N-sided die = N-separate profiles here?  If so, not sure
> what the 'fair' is about?  Taken to the extreme, why not N separate
> profiles, where N is the number of packages?
Fair as in balanced, meaning all the bins are of equal size.  I'm not
stopping you from allocating N bins or even 2N bins, but I would rather
you take the hint and not debate pointless side topics.

> > We disagree about the question whether users should be granted a
> > method of declaring multiple profiles to use for their own purposes
> > in whichever way they see fit through `guix home'.
> 
> I don't?  Well, initially I didn't see a reason for multiple
> profiles, so I asked for reasons, and eventually, a few reasons that
> weren't addressed yet by other things were mentioned (e.g.: tidyness
> of separate profiles, some kind of minimalism where one only has
> packages in $PATH and other search paths that are currently
> neccessary by manually activating a profile that has a selection of
> packages)?
Note that the context has always been placing multiple profiles in
well-defined locations.  It was assumed from the very first post that
you have a use for those, or at the very least that you don't mind
others having a use for them.

> 
> > there is no need to do so whereas I not only claim there is, but
> > also
> > that any existing way of achieving similar results fails to meet my
> > requirements, which are:
> > 
> > 1. multiple profiles can be configured at once
> > 2. profile locations should be specified by the user
> > 3. profile generations are not littered, instead, the user has a
> > way of linking to /var/guix/profiles/per-user
> > 4. both package lists and manifests are supported
> > 5. existing configurations can be expressed in terms of the new
> > system
> > 6. individual profiles can be "disabled", i.e. not sourced during
> > activation, but still built
> > 7. individual profiles can lack a manifest, in which case nothing
> > is built, but they are still sourced on login
> 
> (2) is already achieved by "-p".
Only works for updating, not sourcing, see enabled?
> (4) is already achieved by "-m/ no -m"
See (2).
> (3) not sure why the user would care about /var/guix/profiles/per-
> user
There are very important aesthetic reasons to place generations there
rather than literally in the user's $HOME.
> (7) is already achieved by "guix install" / "guix package -m". The
> ‘source on login’ isn't though -- half-achieved?
It's not.  You can't currently declare a noop profile in any Guix
command.  A noop profile is distinct from an empty profile.

> Remains: (1), (5), (6), (7) not yet completely achieved.
> This kind of list was what I was asking for.
> 
> > [...] along with any underspecified search path
> > For the latter we still need a solution that works regardless of
> > guix home anyway, so it is not a point of discussion here.
> 
> The extra Guix Home feature magnifies the problem of search paths, so
> it seems a point of discussion here to me.  Especially since solving
> it for Guix Home profiles seems a lot less complicated than the
> general case to me: just compute the set of search paths (combined
> over all packages in all the profiles) and use these search paths for
> all the profiles. 
See Andrew's objection in the light of non-managed profiles.  And I
have to agree with Andrew, I don't think computing search paths over
all profiles is the best solution here.  Rather, having search paths be
a first-class citizen of manifests, i.e. allowing them to be specified
in addition to packages, sounds like a solution that works in all
contexts except perhaps the command line without eval.

Cheers