Re: Multiple profiles with Guix Home

[Maxime Devos]

> [...]> I did, but I assumed that people are already aware of multiple
> profile workflows and the pains associated with them.

I am, though in my case profile="guix shell", not "guix package -p".

> Having to debate the semantics of a 2.5 year old blog posts should
> not be necessary in any


I don't think the semantics of
<https://guix.gnu.org/blog/2019/guix-profiles-in-practice/> was debated
anywhere here?  Were there any differing interpretations of that blog
post?

(I forgot about the ‘clean semantic seperation’ initially, but that's
not semantics).

Liliana Marie Prikler schreef op do 05-05-2022 om 22:53 [+0200]:
> 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.


As I understood it, it was introduced as ‘here's a feature proposal’.
By the following messages, I understood it as ‘this feature proposal is
to solve some issues (profile building speed, ...)’ -- i.e., a means to
a goal.  Some goals which appear to me to be able to be solved more
generally and automatically, hence my focus on ‘does this actually help
with these goals?  Can it be solved differently, better or more
generally?’)  Only rather lately it was explained that it was not
intended as a means to some goal (optimisation, etc.) (though it could
help with some of them), but as a goal in itself.

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

Likewise.

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

Likewise.

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

Likewise-ish.

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

Right, I forgot a bit about how profile generations are assigned file
names.

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

I don't know what a ‘noop profile’ is but whatever, I don't think it
matters here given that some other things remain.  Will become clear
once it is implemented I guess.

> See Andrew's objection in the light of non-managed profiles.

I'm not seeing any fragility?  And I'm not seeing the relevancy of non-
managed profiles here -- if it's non-managed how would the alternative
proposal be better there?  And why would Guix Home concern itself with
non-Guix-Home profiles?

Greetings,
Maxime

signature.asc
Description: This is a digitally signed message part