Re: Multiple profiles with Guix Home

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 4018 bytes --]

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?

?

> 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.

> 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?

> 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)?

> You are painfully trying to claim

I don't see anything painful about it, and I'm not anymore.

> 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".
(4) is already achieved by "-m/ no -m"

(3) not sure why the user would care about /var/guix/profiles/per-user

(7) is already achieved by "guix install" / "guix package -m". The
‘source on login’ isn't though -- half-achieved?

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. 

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]