Multiple profiles with Guix Home

Multiple profiles with Guix Home

[Liliana Marie Prikler]

Hi Guix,

it's been a while since the discussion of whether or not to collect
multiple profiles into a single directory [1].  This suggestion takes
inspiration from that, but goes a vastly different route.  Instead of
using environment variables to control Guix, it takes advantage of the
recently added Guix Home, even if it is still a technical preview.

So, what's the proposition?  I suggest we modify home-profile-service-
type (or add a new service) such that it takes a list of <home-profile> 
records instead of a list of packages.  This record would be defined as

  (define-record-type* <home-profile> home-profile
    make-home-profile home-profile? this-home-profile
    (location home-profile-location) ; string, e.g. $HOME/.guix-profile
    (short-name home-profile-short-name) ; string or #f, if given
                                         ; construct a symlink in
                                         ; /var/guix/.../per-user/
    (manifest %home-profile-manifest) ; <manifest> or #f
    (packages home-profile-packages) ; list of <package> or #f
                                     ; fallback for manifest
    (enabled? home-profile-enabled?) ; boolean, default #t
    [...])

  (define (home-profile-manifest home-profile)
    (or (%home-profile-manifest home-profile)
        (and=> (home-profile-packages home-profile) 
               packages->manifest))))

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

Some existing home services would need to be adapted towards this
multiple profile usage.  For instance, home-fontconfig-service-type
would need to accept a list of directories, rather than hardcode its
value.

What do y'all think?

<https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html>

Re: Multiple profiles with Guix Home

[zimoun]

Hi,

On Sun, 03 Oct 2021 at 12:50, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

> it's been a while since the discussion of whether or not to collect
> multiple profiles into a single directory [1].  This suggestion takes
> inspiration from that, but goes a vastly different route.  Instead of
> using environment variables to control Guix, it takes advantage of the
> recently added Guix Home, even if it is still a technical preview.

Thanks for raising up this again.

> So, what's the proposition?  I suggest we modify home-profile-service-
> type (or add a new service) such that it takes a list of <home-profile> 
> records instead of a list of packages.  This record would be defined as

Does it work for Guix on foreign distro?

All the best,
simon

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Hi,

Am Montag, den 04.10.2021, 09:17 +0200 schrieb zimoun:
> Hi,
> 
> On Sun, 03 Oct 2021 at 12:50, Liliana Marie Prikler <
> liliana.prikler@gmail.com> wrote:
> 
> > it's been a while since the discussion of whether or not to collect
> > multiple profiles into a single directory [1].  This suggestion
> > takes inspiration from that, but goes a vastly different
> > route.  Instead of using environment variables to control Guix, it
> > takes advantage of the recently added Guix Home, even if it is
> > still a technical preview.
> 
> Thanks for raising up this again.
> 
> > So, what's the proposition?  I suggest we modify home-profile-
> > service-type (or add a new service) such that it takes a list of
> > <home-profile> records instead of a list of packages.  This record
> > would be defined as
> 
> Does it work for Guix on foreign distro?
I'm not aware of any specific failings w.r.t. foreign-distros on the
part of Guix Home, but I'd recommend waiting for certain bugs to vanish
before seriously using it anyway.  It's probably going to be fine
assuming you can set things up so that you can use Guix Home for your
shell rc files, though it might collide with other software that might
try to do the same.

Long-term, I see Guix Home as beneficial for foreign distros, because
packages would no longer have to code around certain assumptions, but
could instead defer to a home service for configuration, e.g. Guix'
fontconfig could be set up to respect both foreign and Guix' own fonts.

All the best,
Liliana

Re: Multiple profiles with Guix Home

[Andrew Tropin]

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

On 2021-10-03 12:50, Liliana Marie Prikler wrote:

> Hi Guix,
>
> it's been a while since the discussion of whether or not to collect
> multiple profiles into a single directory [1].  This suggestion takes
> inspiration from that, but goes a vastly different route.  Instead of
> using environment variables to control Guix, it takes advantage of the
> recently added Guix Home, even if it is still a technical preview.
>
> So, what's the proposition?  I suggest we modify home-profile-service-
> type (or add a new service) such that it takes a list of <home-profile> 
> records instead of a list of packages.  This record would be defined as
>
>   (define-record-type* <home-profile> home-profile
>     make-home-profile home-profile? this-home-profile
>     (location home-profile-location) ; string, e.g. $HOME/.guix-profile
>     (short-name home-profile-short-name) ; string or #f, if given
>                                          ; construct a symlink in
>                                          ; /var/guix/.../per-user/
>     (manifest %home-profile-manifest) ; <manifest> or #f
>     (packages home-profile-packages) ; list of <package> or #f
>                                      ; fallback for manifest
>     (enabled? home-profile-enabled?) ; boolean, default #t
>     [...])
>
>   (define (home-profile-manifest home-profile)
>     (or (%home-profile-manifest home-profile)
>         (and=> (home-profile-packages home-profile) 
>                packages->manifest))))
>
> 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).  
>
> Some existing home services would need to be adapted towards this
> multiple profile usage.  For instance, home-fontconfig-service-type
> would need to accept a list of directories, rather than hardcode its
> value.
>
> What do y'all think?
>
> <https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html>
>
>

It seems doable, but not sure about costs and benifits.

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.

Another idea I have in mind is to make such profiles (including guix
home's main profile) detached from ~/.config/guix/current.  For example
by providing channels specification as a part of <home-profile>.  It
will make it possible to freeze a costly-to-rebuild profile at a given
channels revisions and not to rebuild it, when the main profile and
channels for it get updated.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Dienstag, dem 03.05.2022 um 17:13 +0300 schrieb Andrew Tropin:
> On 2021-10-03 12:50, Liliana Marie Prikler wrote:
> 
> > Hi Guix,
> > 
> > it's been a while since the discussion of whether or not to collect
> > multiple profiles into a single directory [1].  This suggestion
> > takes inspiration from that, but goes a vastly different route. 
> > Instead of using environment variables to control Guix, it takes
> > advantage of the recently added Guix Home, even if it is still a
> > technical preview.
> > 
> > So, what's the proposition?  I suggest we modify home-profile-
> > service-type (or add a new service) such that it takes a list of
> > <home-profile> records instead of a list of packages.  This record
> > would be defined as
> > 
> >   (define-record-type* <home-profile> home-profile
> >     make-home-profile home-profile? this-home-profile
> >     (location home-profile-location) ; string, e.g. $HOME/.guix-
> > profile
> >     (short-name home-profile-short-name) ; string or #f, if given
> >                                          ; construct a symlink in
> >                                          ; /var/guix/.../per-user/
> >     (manifest %home-profile-manifest) ; <manifest> or #f
> >     (packages home-profile-packages) ; list of <package> or #f
> >                                      ; fallback for manifest
> >     (enabled? home-profile-enabled?) ; boolean, default #t
> >     [...])
> > 
> >   (define (home-profile-manifest home-profile)
> >     (or (%home-profile-manifest home-profile)
> >         (and=> (home-profile-packages home-profile) 
> >                packages->manifest))))
> > 
> > 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).  
> > 
> > Some existing home services would need to be adapted towards this
> > multiple profile usage.  For instance, home-fontconfig-service-type
> > would need to accept a list of directories, rather than hardcode
> > its value.
> > 
> > What do y'all think?
> > 
> > <
> > https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html
> > >
> > 
> > 
> 
> It seems doable, but not sure about costs and benifits.
Glad I have your attention now :)

Depending on your use the time spent building `guix home' could go up
or down.  If you simply add more profiles to it, that'll be an increase
in cost, same if you don't make use of the feature at all due to the
time spent field sanitizing.  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.

> 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, but the fact
that they need to code up their own shell wrappers to manage multiple
profiles is not good optics imo.

> Another idea I have in mind is to make such profiles (including guix
> home's main profile) detached from ~/.config/guix/current.  For
> example by providing channels specification as a part of <home-
> profile>.  It will make it possible to freeze a costly-to-rebuild
> profile at a given channels revisions and not to rebuild it, when the
> main profile and channels for it get updated.
I don't think that's meaningful.  For one, time-machine exists, for the
other you can directly use inferiors in code.  With profiles managed by
Guix Home, you could even make it so that said inferiors are "globally"
managed.  I don't think a manifest consisting of inferior packages only
would require rebuilding.  

Another dirty hack would be to have the manifest evaluate to #f when
you don't want to update it – as per my specification it will in that
case be assumed that you're manually managing it.  Then all you need to
control when to build it is a smart binding of environment variables.

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

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.

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

> [...].  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?  Also, why would the user need to split things,
couldn't Guix do that automatically?

Greetings,
Maxime.

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

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

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

O(n lg n) is almost O(n) (logarithms grow slowly), seems nice.

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

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

I did not suggest any machine learning or AI?  Also, how can a machine
fail here?  The computed partitioning might not be optimal, but as long
as we're careful with search paths and its not overly suboptimal, any
partititioning would do (in the sense that it doesn't ‘lose’ packages
or invent packages oout of thin air or something).

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Maxime Devos schreef op di 03-05-2022 om 22:44 [+0200]:
> Liliana Marie Prikler schreef op di 03-05-2022 om 22:04 [+0200]:
> > > 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.
> 
> I did not suggest any machine learning or AI?  Also, how can a
> machine
> fail here?  The computed partitioning might not be optimal, but as
> long
> as we're careful with search paths and its not overly suboptimal, any
> partititioning would do (in the sense that it doesn't ‘lose’ packages
> or invent packages oout of thin air or something).

Nevermind, see ‘thematic profiles’.

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

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

I did think about this mail.  In particular, the parts about faster
union building.  So my response was about making profiles faster
without having to figure out how to split profiles -- neither manually
(see suggestion about automatic profile splitting) nor automatically
(see O(n²) vs. O(n lg n) union-build).

Until the previous mail, I have not seen anything about thematic
profiles, so I did not have thematic profiles in mind in my response.
Even then, I'm not sure what these thematic profiles are supposed to
solve that is not working around some underlying problem (e.g. slow
profile building times).

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Dienstag, dem 03.05.2022 um 22:59 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op di 03-05-2022 om 22:04 [+0200]:
> > > > 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.
> 
> I did think about this mail.  In particular, the parts about faster
> union building.  So my response was about making profiles faster
> without having to figure out how to split profiles -- neither
> manually (see suggestion about automatic profile splitting) nor
> automatically (see O(n²) vs. O(n lg n) union-build).
Note that I only spoke about costs and benefits in terms of runtime,
because I assumed that to be what Andrew meant by costs and benefits. 
Managing multiple profiles declaratively OTOH is itself a benefit that
ought not be ignored!  Also kn log kn is still bigger than k(n log n).

> Until the previous mail, I have not seen anything about thematic
> profiles, so I did not have thematic profiles in mind in my response.
> Even then, I'm not sure what these thematic profiles are supposed to
> solve that is not working around some underlying problem (e.g. slow
> profile building times).
Pierre's "Guix Profiles in Practice" is a 2.5 years old blog post.  If
you can't think of any uses for multiple profiles, you're not the
target audience at this point.

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op wo 04-05-2022 om 06:16 [+0200]:
> > Until the previous mail, I have not seen anything about thematic
> > profiles, so I did not have thematic profiles in mind in my
> > response.
> > Even then, I'm not sure what these thematic profiles are supposed
> > to
> > solve that is not working around some underlying problem (e.g. slow
> > profile building times).
> Pierre's "Guix Profiles in Practice" is a 2.5 years old blog post. 
> If
> you can't think of any uses for multiple profiles, you're not the
> target audience at this point.
> 

I have seen that blog post.  I do use profiles, albeit with "guix
environment" and now "guix shell".  But I have not yet seen any reasons
for profile _splitting_.  And if I'm not the target audience, what does
that matter?

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Maxime Devos schreef op wo 04-05-2022 om 09:01 [+0200]:
> But I have not yet seen any reasons
> for profile _splitting_.

TBC, I mean splitting into seperate profiles in $GUIX_EXTRA_PROFILES
here, not "guix shell"/manifest.scm-style separate profiles.

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Reza Housseini]

[-- Attachment #1.1.1: Type: text/plain, Size: 1520 bytes --]


On 5/4/22 09:01, Maxime Devos wrote:
> Liliana Marie Prikler schreef op wo 04-05-2022 om 06:16 [+0200]:
>>> Until the previous mail, I have not seen anything about thematic
>>> profiles, so I did not have thematic profiles in mind in my
>>> response.
>>> Even then, I'm not sure what these thematic profiles are supposed
>>> to
>>> solve that is not working around some underlying problem (e.g. slow
>>> profile building times).
>> Pierre's "Guix Profiles in Practice" is a 2.5 years old blog post.
>> If
>> you can't think of any uses for multiple profiles, you're not the
>> target audience at this point.
>>
> I have seen that blog post.  I do use profiles, albeit with "guix
> environment" and now "guix shell".  But I have not yet seen any reasons
> for profile _splitting_.  And if I'm not the target audience, what does
> that matter?
>
> Greetings,
> Maxime.

A specific use case for profile splitting I see very useful, is e.g. 
having a profile with all your editor and plugin dependencies and your 
project specific dependencies. So if you work on a specific project you 
can merge the two profiles and your linters will not complain about 
missing dependencies.

I can also imagine more fine grained splitting, for example test and 
documentation dependencies in separate profiles or even unit test and 
integration test dependencies split into separate profiles.

At the moment I see no possibilities for even the "easy" use case I 
mentioned first.

Cheers,

Reza


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 15557 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Reza Housseini schreef op wo 04-05-2022 om 15:15 [+0200]:
> A specific use case for profile splitting I see very useful, is e.g. 
> having a profile with all your editor and plugin dependencies and
> your 
> project specific dependencies. So if you work on a specific project
> you 
> can merge the two profiles and your linters will not complain about 
> missing dependencies.

That's a use case, but this appears to be already implemented by "guix
shell [-m manifest.scm]"?  Though I suppose there's a use case for
putting the manifests outside the project source code ...

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[zimoun]

Hi,

On Wed, 04 May 2022 at 15:46, Maxime Devos <maximedevos@telenet.be> wrote:

> That's a use case, but this appears to be already implemented by "guix
> shell [-m manifest.scm]"?  Though I suppose there's a use case for
> putting the manifests outside the project source code ...

Well, I miss two things: for one, ’guix shell’ creates a temporary
profile and thus not protected from GC so it can be boring to create
again and again the same profile depending on the frequency you are
working on the project vs the frequency “guix gc” is run.  For two,
’guix shell’ does not guarantee the exact same profile depending if
’guix pull’ had been run in between.

Therefore, many use cases seem around, no?

Otherwise, even ~/.guix-profile is not useful at all since all could be
done with:

    guix time-machine -C channels.scm -- shell -m manifest.scm

(what I do more than often ;-) but not protected from GC either).

For practical reasons, it seems easier to create some profiles and
“load” them (compose?) when required.


Cheers,
simon

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

zimoun schreef op wo 04-05-2022 om 20:14 [+0200]:
> Well, I miss two things: for one, ’guix shell’ creates a temporary
> profile and thus not protected from GC so it can be boring to create
> again and again the same profile depending on the frequency you are
> working on the project vs the frequency “guix gc” is run.  For two,
> ’guix shell’ does not guarantee the exact same profile depending if
> ’guix pull’ had been run in between.
> 
> Therefore, many use cases seem around, no?

The second point is also the case when Guix Home is used.
And at least in some situations, "guix shell" makes GC roots --
guix/scripts/shell.scm has a comment

;; Attempt to compute a file name for use as the cached profile GC root.

.  Maybe not in a sufficient amount of situations though.

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Andrew Tropin]

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

On 2022-05-04 15:15, Reza Housseini wrote:

> On 5/4/22 09:01, Maxime Devos wrote:
>> Liliana Marie Prikler schreef op wo 04-05-2022 om 06:16 [+0200]:
>>>> Until the previous mail, I have not seen anything about thematic
>>>> profiles, so I did not have thematic profiles in mind in my
>>>> response.
>>>> Even then, I'm not sure what these thematic profiles are supposed
>>>> to
>>>> solve that is not working around some underlying problem (e.g. slow
>>>> profile building times).
>>> Pierre's "Guix Profiles in Practice" is a 2.5 years old blog post.
>>> If
>>> you can't think of any uses for multiple profiles, you're not the
>>> target audience at this point.
>>>
>> I have seen that blog post.  I do use profiles, albeit with "guix
>> environment" and now "guix shell".  But I have not yet seen any reasons
>> for profile _splitting_.  And if I'm not the target audience, what does
>> that matter?
>>
>> Greetings,
>> Maxime.
>
> A specific use case for profile splitting I see very useful, is e.g. 
> having a profile with all your editor and plugin dependencies and your 
> project specific dependencies. So if you work on a specific project you 
> can merge the two profiles and your linters will not complain about 
> missing dependencies.
>
> I can also imagine more fine grained splitting, for example test and 
> documentation dependencies in separate profiles or even unit test and 
> integration test dependencies split into separate profiles.
>
> At the moment I see no possibilities for even the "easy" use case I 
> mentioned first.
>

I do some work in rde project for reusing guix home infrastructure
outside of Guix Home for making per-project development environments.
https://youtu.be/knRDdhLRY5Y

This allows to have project dependencies including editor, its plugins
and dependencies of plugins and other stuff available for your project,
but not polluting your main profile or interfer with other projects.
https://youtu.be/pS9JBKdAy4Q

Everything is very much WIP, but I'll document all the stuff in
https://trop.in/rde/manual, when it ready.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Mittwoch, dem 04.05.2022 um 09:01 +0200 schrieb Maxime Devos:
> I have seen that blog post.  I do use profiles, albeit with "guix
> environment" and now "guix shell".  But I have not yet seen any
> reasons for profile _splitting_.  
That's nice for you, but don't take that to mean that no one has any
reason to do so ever.  I personally have my Guix profile already split
across several manifests, that could easily fit into separate profiles
if Guix didn't make working with those an absolute pain.

> And if I'm not the target audience, what does that matter?
It matters because it makes part of your complaint basically "fuck your
use case, mine's already satisfied" (pardon my French).  As for the
other point, which is tangential issues remaining, those deserve fixing
too, but they're not the point of this debate.  Particularly w.r.t.
evaluating search paths across multiple profiles, we already have an
instance of that even without allowing users to specify multiple
profiles easily.  Thus we not only can think about them as different
matters, we should even derive solutions that work outside the context
of guix home!

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op wo 04-05-2022 om 20:38 [+0200]:
> Am Mittwoch, dem 04.05.2022 um 09:01 +0200 schrieb Maxime Devos:
> > I have seen that blog post.  I do use profiles, albeit with "guix
> > environment" and now "guix shell".  But I have not yet seen any
> > reasons for profile _splitting_.  
> That's nice for you, but don't take that to mean that no one has any
> reason to do so ever. 

I don't.

> I personally have my Guix profile already split
> across several manifests, that could easily fit into separate profiles
> if Guix didn't make working with those an absolute pain.

... but separate profiles = separate manifests (except when using "guix
install")?

> > And if I'm not the target audience, what does that matter?
> It matters because it makes part of your complaint basically "fuck your
> use case, mine's already satisfied" (pardon my French).

This was not my complaint.  There are a lot of cool use cases there,
though for whatever reason they were not mentioned in the original e-
mal, so I had to ask what the use cases were.  And FWIW, mine is not
satisfied, profile building is still occassionally a bit on the slow
side.

What is my concern, is that most use cases I have seen mentioned seem
like they can be addressed without extra configuration or records or
manual steps and independently of Guix Home: slow union-build -> make
it faster (linear or at least O(n lg n)), per-project packages -> use
"guix shell -m manifest.scm", things change after "guix pull" -> Guix
Home doesn't solve this(?).  

So except for ‘guix shell maybe doesn't create GC roots sufficiently
often’ and ‘keep things tidy and separate’ (though the latter appears
to be already done by "guix shell"?), I don't see why we need some Guix
Home-specific manual configuration and complexity when we can have some
automatic general optimisations instead.

> As for the
> other point, which is tangential issues remaining, those deserve fixing
> too, but they're not the point of this debate.  Particularly w.r.t.
> evaluating search paths across multiple profiles, we already have an
> instance of that even without allowing users to specify multiple
> profiles easily.  Thus we not only can think about them as different
> matters, we should even derive solutions that work outside the context
> of guix home!

I don't understand this paragraph, weren't these issues the whole
reason for introducing this manual configuration thing?  (And the
thematic profile, which is not tangential IIUC.)

Greetings,
Maxime

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Mittwoch, dem 04.05.2022 um 22:41 +0200 schrieb Maxime Devos:
> 
> > I personally have my Guix profile already split
> > across several manifests, that could easily fit into separate
> > profiles if Guix didn't make working with those an absolute pain.
> 
> ... but separate profiles = separate manifests (except when using
> "guix install")?
This implication really only goes one way, i.e. separate profiles
require separate manifests.  Not that you can't specify multiple
manifests in one file, for instance, ...

> > 
> > > And if I'm not the target audience, what does that matter?
> > It matters because it makes part of your complaint basically "fuck
> > your use case, mine's already satisfied" (pardon my French).
> 
> This was not my complaint.  There are a lot of cool use cases there,
> though for whatever reason they were not mentioned in the original e-
> mail, so I had to ask what the use cases were.  And FWIW, mine is not
> satisfied, profile building is still occassionally a bit on the slow
> side.
> 
> What is my concern, is that most use cases I have seen mentioned seem
> like they can be addressed without extra configuration or records or
> manual steps and independently of Guix Home: slow union-build -> make
> it faster (linear or at least O(n lg n)), per-project packages -> use
> "guix shell -m manifest.scm", things change after "guix pull" -> Guix
> Home doesn't solve this(?).  
You are still debating the legitimacy of splitting ~/.guix-profile and
I don't want to entertain that discussion longer than it's worth.  Just
trust me that there are people, like myself, who *want* to split them.

> So except for ‘guix shell maybe doesn't create GC roots sufficiently
> often’ and ‘keep things tidy and separate’ (though the latter appears
> to be already done by "guix shell"?), I don't see why we need some
> Guix Home-specific manual configuration and complexity when we can
> have some automatic general optimisations instead.
> 
> > As for the other point, which is tangential issues remaining, those
> > deserve fixing too, but they're not the point of this debate. 
> > Particularly w.r.t. evaluating search paths across multiple
> > profiles, we already have an instance of that even without allowing
> > users to specify multiple profiles easily.  Thus we not only can
> > think about them as different matters, we should even derive
> > solutions that work outside the context of guix home!
> 
> I don't understand this paragraph, weren't these issues the whole
> reason for introducing this manual configuration thing?  (And the
> thematic profile, which is not tangential IIUC.)
No, the issues I'm describing is that certain things break when you use
a different profile at all.  For instance, you can't build a font
profile, because both Guix Homeless and Guix Home assume that you're
using their blessed profile to store fonts in.  Such issues can be
solved through configuration, i.e. allowing the user to specify "this
is my font profile and it has fonts".

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 06:25 [+0200]:
> > > across several manifests, that could easily fit into separate
> > > profiles if Guix didn't make working with those an absolute pain.
> > 
> > ... but separate profiles = separate manifests (except when using
> > "guix install")?
> This implication really only goes one way, i.e. separate profiles
> require separate manifests.  Not that you can't specify multiple
> manifests in one file, for instance, ...

What I meant here, is that profiles correspond to manifests (1-1
relation), with the exception of "guix install".  And at least
currently, multiple manifests in a single file appears to be
unsupported?

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 12:53 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 06:25 [+0200]:
> > > > across several manifests, that could easily fit into separate
> > > > profiles if Guix didn't make working with those an absolute
> > > > pain.
> > > 
> > > ... but separate profiles = separate manifests (except when using
> > > "guix install")?
> > This implication really only goes one way, i.e. separate profiles
> > require separate manifests.  Not that you can't specify multiple
> > manifests in one file, for instance, ...
> 
> What I meant here, is that profiles correspond to manifests (1-1
> relation), with the exception of "guix install".  And at least
> currently, multiple manifests in a single file appears to be
> unsupported?
Manifests are scheme code, you can put as many of them into a file as
you want.  For the interface to Guix commands you have to return one at
a time, sure, but that's not the limitation you think it is.

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 18:24 [+0200]:
> Am Donnerstag, dem 05.05.2022 um 12:53 +0200 schrieb Maxime Devos:
> > Liliana Marie Prikler schreef op do 05-05-2022 om 06:25 [+0200]:
> > > > > across several manifests, that could easily fit into separate
> > > > > profiles if Guix didn't make working with those an absolute
> > > > > pain.
> > > > 
> > > > ... but separate profiles = separate manifests (except when using
> > > > "guix install")?
> > > This implication really only goes one way, i.e. separate profiles
> > > require separate manifests.  Not that you can't specify multiple
> > > manifests in one file, for instance, ...
> > 
> > What I meant here, is that profiles correspond to manifests (1-1
> > relation), with the exception of "guix install".  And at least
> > currently, multiple manifests in a single file appears to be
> > unsupported?
> Manifests are scheme code, you can put as many of them into a file as
> you want.  For the interface to Guix commands you have to return one at
> a time, sure, but that's not the limitation you think it is.

Exactly: "guix shell" and the like (currently) only accept a single
manifest.  So at least currently (with the exception of "guix install")
and guix home, profiles correspond to manifests correspond to manifest
files.  And I'm not sure what limitation you are referring to? --
Technically, you can put multiple manifests in a single file, but
currently these extra manifests are meaningless, given that the current
CLI tools only support a single manifest at the time.

Greetigs,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 18:33 +0200 schrieb Maxime Devos:
> > Manifests are scheme code, you can put as many of them into a file
> > as you want.  For the interface to Guix commands you have to return
> > one at a time, sure, but that's not the limitation you think it is.
> 
> Exactly: "guix shell" and the like (currently) only accept a single
> manifest.  
That's not even true.  The manifest flag is repeatable.

> So at least currently (with the exception of "guix install")
> and guix home, profiles correspond to manifests correspond to
> manifest files.  And I'm not sure what limitation you are referring
> to? -- Technically, you can put multiple manifests in a single file,
> but currently these extra manifests are meaningless, given that the
> current CLI tools only support a single manifest at the time.
Exactly.  This limitation is just that, the last line of a file
specified with -m should evaluate to a single manifest.  This does not
imply that a single file can never evaluate to a different manifest
than one it already evaluated to. 

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 19:21 [+0200]:
> Am Donnerstag, dem 05.05.2022 um 18:33 +0200 schrieb Maxime Devos:
> > > Manifests are scheme code, you can put as many of them into a file
> > > as you want.  For the interface to Guix commands you have to return
> > > one at a time, sure, but that's not the limitation you think it is.
> > 
> > Exactly: "guix shell" and the like (currently) only accept a single
> > manifest.  
> That's not even true.  The manifest flag is repeatable.

Interesting, didn't know that.

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 06:25 [+0200]:
> You are still debating the legitimacy of splitting ~/.guix-profile and
> I don't want to entertain that discussion longer than it's worth.  Just
> trust me that there are people, like myself, who *want* to split them.

I am not debating any legitimacy (<home-profile> is not some
government), I am discussing the reasons, and whether some of the
features (e.g. faster profile building) can be implemented more
generally (not Guix Home-exclusive), without manual configuration.  If
some reasons remain (e.g. tidyness of separated thematic profiles),
_those_ reasons could be a good reason for <home-profile> or the like.
What I'd like to avoid, is avoiding extra complexity for the wrong
reasons, and only adding it for the right reasons.

Greetings,
Maxime

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 13:03 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 06:25 [+0200]:
> > You are still debating the legitimacy of splitting ~/.guix-profile
> > and I don't want to entertain that discussion longer than it's
> > worth.  Just trust me that there are people, like myself, who
> > *want* to split them.
> 
> I am not debating any legitimacy (<home-profile> is not some
> government), I am discussing the reasons, and whether some of the
> features (e.g. faster profile building) can be implemented more
> generally (not Guix Home-exclusive), without manual configuration.
I think you're misunderstanding cause and effect here.  For small n,
O(n) = O(1).

> If some reasons remain (e.g. tidyness of separated thematic
> profiles), _those_ reasons could be a good reason for <home-profile>
> or the like.  What I'd like to avoid, is avoiding extra complexity
> for the wrong reasons, and only adding it for the right reasons.
To reiterate, the primary reason for using Guix Home to manage multiple
profiles is so that we can manage multiple profiles in a declarative
manner.  The rest, e.g. smaller build times if you split your profile
along the right cuts, is a result and may for some very well be a
reason to do the split, but it is not the main reason to allow the
split.

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 18:31 [+0200]:
> > I am not debating any legitimacy (<home-profile> is not some
> > government), I am discussing the reasons, and whether some of the
> > features (e.g. faster profile building) can be implemented more
> > generally (not Guix Home-exclusive), without manual configuration.
> I think you're misunderstanding cause and effect here.  For small n,
> O(n) = O(1).

I'm not sure what you mean here, what cause and what effect are you
referring to here?  And I'm not sure what the connection between ‘for
small n, O(n) = O(1)’ and the previous sentences is (I guess something
about profile building times and small profiles -> fast building, but I
don't see any connection to cause and effect ...)?

> If some reasons remain (e.g. tidyness of separated thematic
> profiles), _those_ reasons could be a good reason for <home-profile>
> or the like.  What I'd like to avoid, is avoiding extra complexity
> for the wrong reasons, and only adding it for the right reasons.
> To reiterate, the primary reason for using Guix Home to manage
> multiple profiles is so that we can manage multiple profiles in a
> declarative manner.

Multiple profiles can already be managed in a declarative manner: "guix
shell -m manifest.scm".  I'd say that Guix Home adds some impurity
(‘guix home reconfigure’ installs/removes/replaces some symlinks in
$HOME, which is a form of mutation).  Though maybe some people want to
keep all their manifests together and don't mind the little extra
mutation?

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Maxime Devos schreef op do 05-05-2022 om 18:42 [+0200]:
> Multiple profiles can already be managed in a declarative manner:
> "guix
> shell -m manifest.scm".

Nevermind, I forgot about

> Admittedly, having a disabled profile is not that useful in the
> context
> of guix shell existing, but there might still be some legitimate
> uses.
> For instance, on certain foreign distros in which XDG_DATA_DIRS is
> fragile and precious, you might put graphical applications into an
> extra profile that you source late.

... though this seems a use case already handled by "guix shell"?
Except perhaps for maybe GC'ing too often or being able to build it in
advance or keeping all the manifests in a single place?

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 18:42 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 18:31 [+0200]:
> > > I am not debating any legitimacy (<home-profile> is not some
> > > government), I am discussing the reasons, and whether some of the
> > > features (e.g. faster profile building) can be implemented more
> > > generally (not Guix Home-exclusive), without manual
> > > configuration.
> > I think you're misunderstanding cause and effect here.  For small
> > n, O(n) = O(1).
> 
> I'm not sure what you mean here, what cause and what effect are you
> referring to here?  And I'm not sure what the connection between ‘for
> small n, O(n) = O(1)’ and the previous sentences is (I guess
> something about profile building times and small profiles -> fast
> building, but I don't see any connection to cause and effect ...)?
You get the fast builds because you have small inputs to union-build. 
You can't get small inputs to union-build without splitting your
profile and if everything goes into one profile, you need union-build
in the end.

> > If some reasons remain (e.g. tidyness of separated thematic
> > profiles), _those_ reasons could be a good reason for <home-
> > profile> or the like.  What I'd like to avoid, is avoiding extra
> > complexity for the wrong reasons, and only adding it for the right
> > reasons.  To reiterate, the primary reason for using Guix Home to
> > manage multiple profiles is so that we can manage multiple profiles
> > in a declarative manner.
> 
> Multiple profiles can already be managed in a declarative manner:
> "guix shell -m manifest.scm".  I'd say that Guix Home adds some
> impurity (‘guix home reconfigure’ installs/removes/replaces some
> symlinks in $HOME, which is a form of mutation).  Though maybe some
> people want to keep all their manifests together and don't mind the
> little extra mutation?
We're not talking about the same kind of profile management here.  By
profile management I mean creating, updating, modifying and deleting a
profile that has the same basic properties as ~/.guix-profile or
~/.guix-home.  Shell profiles are not that.

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 19:27 [+0200]:
> > Multiple profiles can already be managed in a declarative manner:
> > "guix shell -m manifest.scm".  I'd say that Guix Home adds some
> > impurity (‘guix home reconfigure’ installs/removes/replaces some
> > symlinks in $HOME, which is a form of mutation).  Though maybe some
> > people want to keep all their manifests together and don't mind the
> > little extra mutation?
> We're not talking about the same kind of profile management here.  By
> profile management I mean creating, updating, modifying and deleting
> a
> profile that has the same basic properties as ~/.guix-profile or
> ~/.guix-home.  Shell profiles are not that.

... ~/.guix-profile and ~/.guix-home profiles do not have the same
basic properties?  ~/.guix-profile is to be managed imperatively with
"guix install", "guix package -u" or such or semi-imperatively mostly-
declaratively with "guix package -m" , whereas ~/.guix-home is in
theory only to be managed with "guix home reconfigure"?"

And except for not having a location in $HOME somewhere and not being
mutatable, if that's you mean, "guix shell" produces the same kind of
profile as "guix home" AFAICT?

Or are you referring to home-shell-profile-configuration, which is yet
another thing?

Greetings,
Maxime

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 19:41 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 19:27 [+0200]:
> > We're not talking about the same kind of profile management here. 
> > By profile management I mean creating, updating, modifying and
> > deleting a profile that has the same basic properties as ~/.guix-
> > profile or ~/.guix-home.  Shell profiles are not that.
> 
> ... ~/.guix-profile and ~/.guix-home profiles do not have the same
> basic properties?  ~/.guix-profile is to be managed imperatively with
> "guix install", "guix package -u" or such or semi-imperatively
> mostly-declaratively with "guix package -m" , whereas ~/.guix-home is
> in theory only to be managed with "guix home reconfigure"?"
And would you look at this, my proposed solution would make ~/.guix-
home a profile that can be managed by `guix package', or even be
dropped in favour of ~/.guix-profile or any list of profiles.  This
also extends to the pull profile, which can be moved to a different
location, assuming you use `guix pull -p' and specify the pull profile
as an enabled empty profile.

> And except for not having a location in $HOME somewhere and not being
> mutatable, if that's you mean, "guix shell" produces the same kind of
> profile as "guix home" AFAICT?
Sure.  "guix system disk-image" also produces the same kind of profile,
but it's better hidden.  That's not the point.

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 21:17 [+0200]:
> Am Donnerstag, dem 05.05.2022 um 19:41 +0200 schrieb Maxime Devos:
> > Liliana Marie Prikler schreef op do 05-05-2022 om 19:27 [+0200]:
> > > We're not talking about the same kind of profile management here. 
> > > By profile management I mean creating, updating, modifying and
> > > deleting a profile that has the same basic properties as ~/.guix-
> > > profile or ~/.guix-home.  Shell profiles are not that.
> > 
> > ... ~/.guix-profile and ~/.guix-home profiles do not have the same
> > basic properties?  ~/.guix-profile is to be managed imperatively with
> > "guix install", "guix package -u" or such or semi-imperatively
> > mostly-declaratively with "guix package -m" , whereas ~/.guix-home is
> > in theory only to be managed with "guix home reconfigure"?"
> And would you look at this, my proposed solution would make ~/.guix-
> home a profile that can be managed by `guix package'

I do not see this in the proposal?  Or, as I think has been implied by
other messages but not by the proposal, 'manifest=#false' would create
a profile (if it does not exist already) that can be modified with
"guix install" etc, without changes being overridden by future "guix
home reconfigure"?

Greeetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 21:42 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 21:17 [+0200]:
> > And would you look at this, my proposed solution would make
> > ~/.guix-home a profile that can be managed by `guix package'
> 
> I do not see this in the proposal?  Or, as I think has been implied
> byother messages but not by the proposal, 'manifest=#false' would
> create a profile (if it does not exist already) that can be modified
> with "guix install" etc, without changes being overridden by future
> "guix home reconfigure"?
To be fair, the proposal was rather sparse, but
> `guix home' creates/updates all home-profiles which have a home-
> profile-manifest that is not #f
meaning that if you specify ~/.guix-home without packages or a manifest
(thus making its home-profile-manifest #f), it does not create/update
the profile.  My wording differs from yours in that mine does not imply
that the directory is created if none exists, but yours is the saner
option here, so we may want to add that check.

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 19:27 [+0200]:
> > I'm not sure what you mean here, what cause and what effect are you
> > referring to here?  And I'm not sure what the connection between
> > ‘for
> > small n, O(n) = O(1)’ and the previous sentences is (I guess
> > something about profile building times and small profiles -> fast
> > building, but I don't see any connection to cause and effect ...)?
> You get the fast builds because you have small inputs to union-build.
> You can't get small inputs to union-build without splitting your
> profile and if everything goes into one profile, you need union-build
> in the end.

I assume you mean ‘cause = tinier profiles’ and ‘effect = faster build
times’ here?

That's one method for faster builds, but you'll get even faster builds
by also making union-build O(n lg n) instead of O(n²), and the latter
optimisation will help everyone and not only Guix Home users.

And the O(n)=O(1) doesn't seem quite right here to me -- individual
profiles will be smaller and hence faster, but there will also be
_more_ profiles.  Maybe if you sum over the profiles, you'll get to
O(n) instead of O(n²) (where n = number of store items in the
profiles), but this doesn't take in account the _user_'s time cost of
having to figure out some kind of thematic split that doesn't break
search paths.  Or worse, if the user doesn't know what search paths are
and when they can break.

Also, I still don't see the relation to

> > I am not debating any legitimacy (<home-profile> is not some
> > government), I am discussing the reasons, and whether some of the
> > features (e.g. faster profile building) can be implemented more
> > generally (not Guix Home-exclusive), without manual configuration.
> > [...]

-- I mention the phrase ‘faster profile building’ here, but I don't
think I'm implying here that faster build times cause tinier profiles,
or that tinier profiles don't help or such?  Is there some specific
phrase in that paragraph you disagree with?  Is there some point you
consider to be already addressed or not yet addressed or some point you
consider to not have to be addressed?  I don't know what we are
disagreeing about here?

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 20:00 +0200 schrieb Maxime Devos:
> That's one method for faster builds, but you'll get even faster
> builds by also making union-build O(n lg n) instead of O(n²), and the
> latter optimisation will help everyone and not only Guix Home users.
If that's what you want then go ahead and improve union-build.  Unless
you add some serious waste that eats up thousands of cycles if supplied
with no more than three packages, I doubt it has any serious effect on
my analysis that small n = better.

As for the complexity of the actual implementation, I'm pretty sure
you'll find it to be n log n in most cases, but I also fear that there
might be degenerate cases in which the fact that we're reporting errors
at all leads to a worst case lower bound of O(n²). 

> And the O(n)=O(1) doesn't seem quite right here to me -- individual
> profiles will be smaller and hence faster, but there will also be
> _more_ profiles.  Maybe if you sum over the profiles, you'll get to
> O(n) instead of O(n²) (where n = number of store items in the
> profiles)
Again, k(n log n) <= nk log nk, for k >= 1.

> But this doesn't take in account the _user_'s time cost of
> having to figure out some kind of thematic split that doesn't break
> search paths.
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.

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.  What could be more fair than a
six-sided die?  Why, a seven-sided die of course!

> Or worse, if the user doesn't know what search paths are and when
> they can break.
> 
> Also, I still don't see the relation to
> 
> > > I am not debating any legitimacy (<home-profile> is not some
> > > government), I am discussing the reasons, and whether some of the
> > > features (e.g. faster profile building) can be implemented more
> > > generally (not Guix Home-exclusive), without manual
> > > configuration.
> > > [...]
> 
> -- I mention the phrase ‘faster profile building’ here, but I don't
> think I'm implying here that faster build times cause tinier
> profiles, or that tinier profiles don't help or such?  Is there some
> specific phrase in that paragraph you disagree with?  Is there some
> point you consider to be already addressed or not yet addressed or
> some point you consider to not have to be addressed?  I don't know
> what we are disagreeing about here?
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'.  You are painfully
trying to claim 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

With all of the above, home-profile-service would make most of the
currently existing /etc/profile workarounds obsolete.  The exception
would be that /run/setuid-binaries is missing, 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.

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 21:08 [+0200]:
> > And the O(n)=O(1) doesn't seem quite right here to me -- individual
> > profiles will be smaller and hence faster, but there will also be
> > _more_ profiles.  Maybe if you sum over the profiles, you'll get to
> > O(n) instead of O(n²) (where n = number of store items in the
> > profiles)
> Again, k(n log n) <= nk log nk, for k >= 1.

Logarithms are mostly neglible though in practice?
And

  kn log nk = kn log n + kn log k ≅ kn log n

for small 'log k'.

Greetings
Maxime.

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

Re: Multiple profiles with Guix Home

[zimoun]

On Thu, 05 May 2022 at 21:44, Maxime Devos <maximedevos@telenet.be> wrote:

>> Again, k(n log n) <= nk log nk, for k >= 1.
>
> Logarithms are mostly neglible though in practice?
> And
>
>   kn log nk = kn log n + kn log k ≅ kn log n
>
> for small 'log k'.

From a practical point of view,

1. this complexity of O(n log n) is from a magic hat.

2. n and k are the same order of magnitude; say n from 10 to 100 and k
   from 5 to 50, from my magic hat.

3. this discussion about complexity is totally pointless.

Cheers,
simon

Re: Multiple profiles with Guix Home

[Maxime Devos]

[-- 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 --]

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

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

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 23:28 +0200 schrieb Maxime Devos:
> 
> > 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?
IMHO, you are ignoring the very obvious GUIX_EXTRA_PROFILES stuff,
because "we have guix shell".  No, guix shell is not a solution to this
problem.

> 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.
Again, Andrew spoke about costs and benefits, wherein I assumed he
meant the costs and benefits of building multiple profiles in Guix Home
vs. building a single profile.  I already clarified this
misunderstanding (or at least assumed I did).

> > 
> > > (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.
In this case it's a home-profile that leads to no build action.  The
very concept has no meaning outside of managing multiple profiles,
because it is always assumed you're modifying a particular one (or
working on a transient one in the case of guix shell).

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

So as to figure out the right order w.r.t. PATH shadowing.  For
instance, this proposal would allow you to install Guix extensions in a
well-known location while guix itself is still the one that's used by
guix pull.  In order to do that, you need to set up current-guix as a
noop profile and the extensions inside a profile that's below it in the
search path.

Cheers

Re: Multiple profiles with Guix Home

[Ludovic Courtès]

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> Am Donnerstag, dem 05.05.2022 um 23:28 +0200 schrieb Maxime Devos:
>> 
>> > 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?
> IMHO, you are ignoring the very obvious GUIX_EXTRA_PROFILES stuff,
> because "we have guix shell".  No, guix shell is not a solution to this
> problem.

Hey comrades, hold your horses!  That’s an inspiring topic that we have
here, but we can make the thread friendlier and a bit more terse I’m
sure.  :-)

Re: Multiple profiles with Guix Home

[zimoun]

On Thu, 05 May 2022 at 21:08, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> Am Donnerstag, dem 05.05.2022 um 20:00 +0200 schrieb Maxime Devos:
>
>> That's one method for faster builds, but you'll get even faster
>> builds by also making union-build O(n lg n) instead of O(n²), and the
>> latter optimisation will help everyone and not only Guix Home users.
>
> If that's what you want then go ahead and improve union-build.  Unless
> you add some serious waste that eats up thousands of cycles if supplied
> with no more than three packages, I doubt it has any serious effect on
> my analysis that small n = better.
>
> As for the complexity of the actual implementation, I'm pretty sure
> you'll find it to be n log n in most cases, but I also fear that there
> might be degenerate cases in which the fact that we're reporting errors
> at all leads to a worst case lower bound of O(n²). 
>
>> And the O(n)=O(1) doesn't seem quite right here to me -- individual
>> profiles will be smaller and hence faster, but there will also be
>> _more_ profiles.  Maybe if you sum over the profiles, you'll get to
>> O(n) instead of O(n²) (where n = number of store items in the
>> profiles)
> Again, k(n log n) <= nk log nk, for k >= 1.

Well, I am not sure I understand all the debate here.

Again, without concrete timings, the discussion is purely theoretical.
And from my experience, the update of several profiles at once is
usually much faster that an unique big profile update.  For sure, the
situation is improving with recent work, but still.

Maxime, assuming the user has {n_i} packages for i in {1,..,k} profiles,
i.e., a total of N = sum n_i packages.  If the installation, update or
any other operation on one profile has the cost f(n) for n package in
this very same profile, then the comparison becomes

    sum f(n_i)
vs
    f(sum n_i)

and thus –except special cases for the ’f’ cost– considering the most
probable non-linear shapes of ’f’, multi-profile is always better.

(Note that this ’f’ probably depends on the set of packages, so it is
even more complicated, IMHO)


Now, assume the user has, in average, n packages per profile.
Therefore, it becomes,

    k f(n)
vs
    f(k n)

and if f(n) = n log n, then it becomes,

    k n log n
vs
    k n (log n + log k)

and thus, Liliana, in this very specific case of complexity – probably
not the real one –, the pragmatical question is ’n’ vs ’k’ vs the hidden
constant (for all the IO).



Again, I miss the debate. :-)


Cheers,
simon

Re: Multiple profiles with Guix Home

[zimoun]

On Thu, 05 May 2022 at 18:31, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

>                                                         For small n,
> O(n) = O(1).

I guess, you meant that, for small n, the time of O(n) is dominated by
the constant.

Note that, obviously, the real time depends also on the constant hidden
by O notation.  Other said, depending on the range for n, an algorithm
of complexity O(n^2), or worse, can be faster (time) than another
algorithm of complexity O(1).  However, the scaling-up will be
different, obviously. :-)

Without concrete timings about Guix profiles, I would avoid to speak
about complexity. ;-) I bet that for most cases about profiles, the
concrete real time is dominated by the constants (I/O).

Cheers,
simon

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

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

In practice, ‘nice to have later’ becomes virtually never, see e.g. not
building dependencies again and again and not having to build dozens of
variants of a package (go-build-system (*) and cargo-build-system (**).
As such, I'd rather have ‘now’.

Also, this sounds like adding a new feature (multiple profiles for Guix
Home) at cost of an extra (known) bug (these multiple profiles don't
share search paths).

(*) used to be reasonable 4 years ago, marked as ‘not a blocker’ and
then neglected, see
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32919#5>) 
(**) Currently being addressed with antioxidant-build-system (WIP)

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Dienstag, dem 03.05.2022 um 23:11 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op di 03-05-2022 om 22:04 [+0200]:
> > 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.
> 
> In practice, ‘nice to have later’ becomes virtually never, see e.g.
> not building dependencies again and again and not having to build
> dozens of variants of a package (go-build-system (*) and cargo-build-
> system (**). As such, I'd rather have ‘now’.
In practice, this is still not a blocker, because extra inputs for
search paths affect neither the purity nor the union-build much.

> Also, this sounds like adding a new feature (multiple profiles for
> Guix Home) at cost of an extra (known) bug (these multiple profiles
> don't share search paths).
Hyrum's Law might also come in play here.  Thus an alternative would
not be sharing search paths, but making those search paths themselves a
part of manifests.  However, while either would be doable if we
bikeshed enough, having a known bug persist while we solve an important
other issue is imho preferable to waiting until we all agree about
what's to be done with it.


Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op wo 04-05-2022 om 06:23 [+0200]:
> > Also, this sounds like adding a new feature (multiple profiles for
> > Guix Home) at cost of an extra (known) bug (these multiple profiles
> > don't share search paths).
> Hyrum's Law might also come in play here.

... how can an user come to depend on internals that do not yet exist?
Also, Hyrum's Law only says that assumptions about the implementation
will eventually be made, not that these assumptions can't be broken
later.

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op wo 04-05-2022 om 06:23 [+0200]:
> Am Dienstag, dem 03.05.2022 um 23:11 +0200 schrieb Maxime Devos:
> > Liliana Marie Prikler schreef op di 03-05-2022 om 22:04 [+0200]:
> > > 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.
> > 
> > In practice, ‘nice to have later’ becomes virtually never, see e.g.
> > not building dependencies again and again and not having to build
> > dozens of variants of a package (go-build-system (*) and cargo-build-
> > system (**). As such, I'd rather have ‘now’.
> In practice, this is still not a blocker, because extra inputs for
> search paths affect neither the purity nor the union-build much.

... I did not say anything about purity or union-build here?
Search paths are independent of union-build.

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Andrew Tropin]

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

On 2022-05-03 20:34, Liliana Marie Prikler wrote:

> Am Dienstag, dem 03.05.2022 um 17:13 +0300 schrieb Andrew Tropin:
>> On 2021-10-03 12:50, Liliana Marie Prikler wrote:
>> 
>> > Hi Guix,
>> > 
>> > it's been a while since the discussion of whether or not to collect
>> > multiple profiles into a single directory [1].  This suggestion
>> > takes inspiration from that, but goes a vastly different route. 
>> > Instead of using environment variables to control Guix, it takes
>> > advantage of the recently added Guix Home, even if it is still a
>> > technical preview.
>> > 
>> > So, what's the proposition?  I suggest we modify home-profile-
>> > service-type (or add a new service) such that it takes a list of
>> > <home-profile> records instead of a list of packages.  This record
>> > would be defined as
>> > 
>> >   (define-record-type* <home-profile> home-profile
>> >     make-home-profile home-profile? this-home-profile
>> >     (location home-profile-location) ; string, e.g. $HOME/.guix-
>> > profile
>> >     (short-name home-profile-short-name) ; string or #f, if given
>> >                                          ; construct a symlink in
>> >                                          ; /var/guix/.../per-user/
>> >     (manifest %home-profile-manifest) ; <manifest> or #f
>> >     (packages home-profile-packages) ; list of <package> or #f
>> >                                      ; fallback for manifest
>> >     (enabled? home-profile-enabled?) ; boolean, default #t
>> >     [...])
>> > 
>> >   (define (home-profile-manifest home-profile)
>> >     (or (%home-profile-manifest home-profile)
>> >         (and=> (home-profile-packages home-profile) 
>> >                packages->manifest))))
>> > 
>> > 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).  
>> > 
>> > Some existing home services would need to be adapted towards this
>> > multiple profile usage.  For instance, home-fontconfig-service-type
>> > would need to accept a list of directories, rather than hardcode
>> > its value.
>> > 
>> > What do y'all think?
>> > 
>> > <
>> > https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html
>> > >
>> > 
>> > 
>> 
>> It seems doable, but not sure about costs and benifits.
> Glad I have your attention now :)
>
> Depending on your use the time spent building `guix home' could go up
> or down.  If you simply add more profiles to it, that'll be an increase
> in cost, same if you don't make use of the feature at all due to the
> time spent field sanitizing.  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.
>

Yep, I already face some relatively long builds of profiles, I don't
remember when I started to face it, but splitting into a few independent
profile can make the situation better, need to experiment with it.

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

It won't work if we have "managed outside" profiles and overall seems
quite fragile.

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

Sounds reasonable.

>> Another idea I have in mind is to make such profiles (including guix
>> home's main profile) detached from ~/.config/guix/current.  For
>> example by providing channels specification as a part of <home-
>> profile>.  It will make it possible to freeze a costly-to-rebuild
>> profile at a given channels revisions and not to rebuild it, when the
>> main profile and channels for it get updated.
> I don't think that's meaningful.  For one, time-machine exists, for the
> other you can directly use inferiors in code.  With profiles managed by
> Guix Home, you could even make it so that said inferiors are "globally"
> managed.  I don't think a manifest consisting of inferior packages only
> would require rebuilding.  

I had some issues with inferiors previously, but will see, maybe it will
work for me.

> Another dirty hack would be to have the manifest evaluate to #f when
> you don't want to update it – as per my specification it will in that
> case be assumed that you're manually managing it.  Then all you need to
> control when to build it is a smart binding of environment variables.

Sounds hacky :)  Better to utilize inferiors here IMO.

I'm not sure when I get a spare time to experiment with this feature,
but I'll let you know.  In case you would draft an implemntation before
that, please share, I'll test it out and we can further discuss it.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

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

Greetings,
Maxime.



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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

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.  "enabled?" here really means "sourced
on startup", i.e. "enabled by default" when you launch a shell. 
Admittedly, having a disabled profile is not that useful in the context
of guix shell existing, but there might still be some legitimate uses.
For instance, on certain foreign distros in which XDG_DATA_DIRS is
fragile and precious, you might put graphical applications into an
extra profile that you source late.  Or for debugging purposes, you
could set aside a profile that contains just coreutils and less, so
that from /tmp/guix-build-... you can source that rather than a full-
blown profile (after evaluating environment-variables, you won't have
access to guix!)

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

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.

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?

Greetings,
Maxim

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

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

This doesn't work for
SSL_CERT_DIR/SSL_CERT_FILE/GUIX_LOCALEPATH/PYTHON_TZPATH if the user
has a thematic ‘data’ profile containing certificates, timezones and
locales.  

Also, this seems like a limitation that the user needs to be aware
of (and hence documented).  Why give the user something buggy and
inform the user that its buggy, when it can be made non-buggy?

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 19:29 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 19:19 [+0200]:
> > 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 [...]
> 
> This doesn't work for SSL_CERT_DIR/SSL_CERT_FILE
nss-certs can be installed to their own profile and referenced from
there, but are typically part of the OS config.  No glaring issue here.

> GUIX_LOCALEPATH
Does this affect applications other than Guix itself?

> PYTHON_TZPATH 
Don't know anything about this one tbh.

> Also, this seems like a limitation that the user needs to be aware
> of (and hence documented).  Why give the user something buggy and
> inform the user that its buggy, when it can be made non-buggy?
Why do we have a section "Application Setup" in our manual?  Shouldn't
we make it so that no application requires setup?

The variables you quoted above are an exception rather than a rule. 
Though to be fair, I disagree with said variables not only for this
reason, but also because they break similar setups with `guix shell'. 
Again, the long-term goal is to eliminate such bugs and we can do that
by making those PATH variables support multiple directories.

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 20:24 [+0200]:
> > GUIX_LOCALEPATH
> Does this affect applications other than Guix itself?

Yes, every glibc-using package.  It's where glibc looks for glibc
locales.

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 22:14 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 20:24 [+0200]:
> > > GUIX_LOCPATH [note: I corrected this now]
> > Does this affect applications other than Guix itself?
> 
> Yes, every glibc-using package.  It's where glibc looks for glibc
> locales.
Fair enough, but we still only need one of that, which is where glibc-
locales is installed.  Any profile will do here.  In fact, IIRC this
only affects foreign distros even, and afaik does not have anything to
do with other i18n, so for instance if you run a command that's not
already in your profile and it uses gettext, that command should
already be set up to work correctly.

Case in point: `guix shell recutils -- recsel --help' prints help in
German on my end.

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 22:27 [+0200]:
> and afaik does not have anything to
> do with other i18n,

It is needed to get UTF-8 file name decoding in Guile, IIUC.

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 22:27 [+0200]:
> Am Donnerstag, dem 05.05.2022 um 22:14 +0200 schrieb Maxime Devos:
> > Liliana Marie Prikler schreef op do 05-05-2022 om 20:24 [+0200]:
> > > > GUIX_LOCPATH [note: I corrected this now]
> > > Does this affect applications other than Guix itself?
> > 
> > Yes, every glibc-using package.  It's where glibc looks for glibc
> > locales.
> Fair enough, but we still only need one of that, which is where glibc-
> locales is installed.  Any profile will do here.

Like with SSL_CERT_DIR, not any profile will do!  glibc-locales must be
present in a profile that has a package with the GUIX_LOCPATH search
path, otherwise Guix won't define the $GUIX_LOCPATH environment
variable.

In practice, this means that "glibc" needs to be added to the profile
that contains "glibc-locales".

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op do 05-05-2022 om 20:24 [+0200]:
> > This doesn't work for SSL_CERT_DIR/SSL_CERT_FILE
> nss-certs can be installed to their own profile and referenced from
> there

No, if it is installed in its own profile, then
SSL_CERT_DIR/SSL_CERT_FILE won't be set:

* Put nss-certs its own 'certificates' profile.
* Put curl in a 'applications' profile.

'curl' has a SSL_CERT_FILE search path.  However, its profile does not
have the etc/ssl/certs/ca-certificates.crt, so the SSL_CERT_FILE
environment variable will not be defined for 'applications'

nss-certs does not have any search paths, so the 'certificates' profile
doesn't have any either.

> [...], but are typically part of the OS config.  No glaring issue
> here.

If I install a certificate package, then I expect my certificates to be
actually used, instead of the system's certificates (except for the
GNUtls just-use-/etc/ssl/certs limitation for which there's a WIP patch
to be integrated, and certifi packages for which there's a separate
Guix issue).

Especially since ‘Guix Home’ is about _home_, not _system_ (so no
having to rely on the system administrator), and since ‘Guix Home’ is
about declarativity so I expect it to respect the certificates I
declared.  And especially since the limitation ‘nss-certs won't work
when using separated Guix Home profiles’ isn't documented.

More generally, not having to rely on the OS config is almost in the
(guix)Introduction:

> Guix makes it easy for _unprivileged_ users to install, upgrade,
> or remove software packages, to roll back to a previous package set,
> to build packages from source, and generally assists with the
> creation and maintenance of software environments.

(emphasis mine).

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 22:26 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 20:24 [+0200]:
> > > This doesn't work for SSL_CERT_DIR/SSL_CERT_FILE
> > nss-certs can be installed to their own profile and referenced from
> > there
> 
> No, if it is installed in its own profile, then
> SSL_CERT_DIR/SSL_CERT_FILE won't be set:
> 
> * Put nss-certs its own 'certificates' profile.
> * Put curl in a 'applications' profile.
> 
> 'curl' has a SSL_CERT_FILE search path.  However, its profile does
> not have the etc/ssl/certs/ca-certificates.crt, so the SSL_CERT_FILE
> environment variable will not be defined for 'applications'
Note that 'applications' is not really a useful category.  But what's
more both nss-certs, glibc-locales and other packages that on their own
provide everything you need in a search path can already be handled
easily with existing mechanisms of Guix Home.  This is not a use case
that calls for multiple profiles and the fix to missing these single
packages (assuming you want it expressed solely in terms of profiles)
would be to add them back to the default profile which still has its
uses no matter how clean you want the split to be.


Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

Liliana Marie Prikler schreef op vr 06-05-2022 om 20:40 [+0200]:
> Note that 'applications' is not really a useful category.

It is a clear thematic division to me.  Though it's a bit large, maybe
'applications' could be divided futher in more specific themes
(‘office’ apps, games, terminal utilities, ...).

>  But what's
> more both nss-certs, glibc-locales and other packages that on their own
> provide everything you need in a search path can already be handled
> easily with existing mechanisms of Guix Home.

I haven't found any such mechanism -- I haven't found any hits for
'GUIX_LOCPATH' or SSL_CERT_DIR/FILE'.  At most I've found 'environment-
variables->setup-environment-script', but as user I just want to add
packages to a profile and have it work without having to manually
fiddle with environemnt variables.

> This is not a use case that calls for multiple profiles

A separate 'data' profile looks like a use case for multiple thematic
profiles to me.  As I understood it, being able to separate profiles as
you like is the point of the proposed Guix Home?  Why prevent the user
from making a ‘data’ profile?  Maybe a separate profile for time zones,
certificates and locales doesn't seem useful to you, but it seems a
practical subdivison to me.

> and the fix to missing these single
> packages (assuming you want it expressed solely in terms of profiles)
> would be to add them back to the default profile 

Merging the 'data' profile (or other profiles) back into another
profile kind of defeats the purpose of aseparate profiles.  What if I
don't have any default profile (or if a default profile is technically
required, keep it empty)?


Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Freitag, dem 06.05.2022 um 21:54 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op vr 06-05-2022 om 20:40 [+0200]:
> > Note that 'applications' is not really a useful category.
> 
> It is a clear thematic division to me.  Though it's a bit large,
> maybe 'applications' could be divided futher in more specific themes
> (‘office’ apps, games, terminal utilities, ...).
Yeah, that division makes more sense, but note that none of the
categories you cited call specifically for SSL_CERT_DIR/FILE.  It
really is curl, which you might categorize as "terminal utility", but
more accurately fits into "web" along with nss-certs, for example.

> > But what's more both nss-certs, glibc-locales and other packages
> > that on their own provide everything you need in a search path can
> > already be handled easily with existing mechanisms of Guix Home.
> 
> I haven't found any such mechanism -- I haven't found any hits for
> 'GUIX_LOCPATH' or SSL_CERT_DIR/FILE'.  At most I've found
> 'environment-variables->setup-environment-script', but as user I just
> want to add packages to a profile and have it work without having to
> manually fiddle with environemnt variables.
I'm pretty sure Guix Home allows you to write your bashrc with gexps,
no?  So you could put (string-append "export SSL_CERT_DIR=" #$nss-certs
"/etc/ssl/certs") in there IIRC.

> > This is not a use case that calls for multiple profiles
> 
> A separate 'data' profile looks like a use case for multiple thematic
> profiles to me.  As I understood it, being able to separate profiles
> as you like is the point of the proposed Guix Home?  Why prevent the
> user from making a ‘data’ profile?  Maybe a separate profile for time
> zones, certificates and locales doesn't seem useful to you, but it
> seems a practical subdivison to me.
Perhaps, but this requires more than simply a declarative way of
managing profiles, which is the main point here.  It would require
search-paths as first class citizens of profiles in addition to that,
which I already mentioned a few times in between.

> > and the fix to missing these single packages (assuming you want it
> > expressed solely in terms of profiles) would be to add them back to
> > the default profile 
> 
> Merging the 'data' profile (or other profiles) back into another
> profile kind of defeats the purpose of aseparate profiles.  What if I
> don't have any default profile (or if a default profile is
> technically required, keep it empty)?
Well, even if you name it "data" your data profile would then be the de
facto default profile.  For the record, I'm not saying that the default
profile in ~/.guix-profile would be a hard requirement going forward,
because to a certain extent, managing multiple profiles with Guix Home
already addresses both the choice of its name and its location.  What
it does not (yet) address is the fact that you'll probably have a
kitchen sink profile left after neatly sorting all the other packages
into themes.  For now this seems to be as much a technical limitation
as it is a condition of human nature.  I'm fairly certain that we'll
start to see such extensions once we've implemented the system and
people are dissatisfied with the fact that they can't have a meaningful
data profile – thus either extending the home-profile-service-type to
account for those or finding other solutions that compose well through
guix home or guix itself.

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

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

> > It is a clear thematic division to me.  Though it's a bit large,
> > maybe 'applications' could be divided futher in more specific
> themes
> > (‘office’ apps, games, terminal utilities, ...).
> Yeah, that division makes more sense, but note that none of the
> categories you cited call specifically for SSL_CERT_DIR/FILE.  It
> really is curl, which you might categorize as "terminal utility", but
> more accurately fits into "web" along with nss-certs, for example.

I don't have 'curl' or 'wget' installed.

'minetest' falls under games and can be used offline, yet it requires
SSL_CERT_DIR/FILE for contacting its ‘mod’ server ContentDB.

In the past, I've had a 'calibre' package installed, which in some
usage modes contacts the network and needs TLS certificates (I don't
know if it respect SSL_CERT_DIR/SSL_CERT_FILE) -- I guess I would
classify it as ‘office‘, not ‘web’

'emacs' can be used to browse the ‘web’ (and hence might respect
SSL_CERT_DIR/SSL_CERT_FILE, not sure), yet it would be classified as
maybe ‘office’ but not ‘web’.

I guess ‘git’ could be classified as ‘web’, but it seems more something
for ‘terminal utilities’ or such to me, and it uses certificates for
repositories over https://.

‘gpg’ looks like something for ‘terminal utilities’ to me, yet it can
contact keyservers (though I'm not sure it can do so over HTTPS), which
might need certificates (I don't know if it respects
SSL_CERT_DIR/SSL_CERT_FILE).

'vlc' can stream videos from over the Internet (over HTTP or HTTPS), so
it might need certificates (I don't know if it respects
SSL_CERT_DIR/SSL_CERT_FILE), but it doesn't seem like ‘web’ to me.

AFAICT, the only for reason SSL_CERT_DIR/SSL_CERT_FILE would be set on
my system, is the ‘youtube-dl’ package (that is, once the search path
is added to the package), and the ‘openssl’ package, which AFAICT was
only installed to work around ‘SSL_CERT_DIR/SSL_CERT_FILE is not set
because many packages forget SSL_CERT_DIR/SSL_CERT_FILE in the native-
search-paths'.

Liliana Marie Prikler schreef op vr 06-05-2022 om 23:32 [+0200]:
> > > But what's more both nss-certs, glibc-locales and other packages
> > > that on their own provide everything you need in a search path
> > > can
> > > already be handled easily with existing mechanisms of Guix Home.
> > 
> > I haven't found any such mechanism -- I haven't found any hits for
> > 'GUIX_LOCPATH' or SSL_CERT_DIR/FILE'.  At most I've found
> > 'environment-variables->setup-environment-script', but as user I
> > just
> > want to add packages to a profile and have it work without having
> > to
> > manually fiddle with environemnt variables.
> I'm pretty sure Guix Home allows you to write your bashrc with gexps,
> no?  So you could put (string-append "export SSL_CERT_DIR=" #$nss-
> certs "/etc/ssl/certs") in there IIRC.

That's the kind of manual fiddling I was referring to (I don't want to
have to known any Bash more complicated that just starting some
binary), which I'd like Guix Home to automatically do for me instead. 
Why can't Guix (Home) do this for me?  Also, ~/.bashrc is Bash
specific, did you mean ~/.profile or .../etc/profile instead?

> > [search paths things]
> Perhaps, but this requires more than simply a declarative way of
> managing profiles, which is the main point here.  It would require
> search-paths as first class citizens of profiles in addition to that,
> which I already mentioned a few times in between.

As such, I consider addressing the search paths limitation a
requirement for the new ‘separated profiles with Guix Home’, though as
I understand it, you do not consider it to be a blocker?

Greetings,
Maxime.

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

Re: Multiple profiles with Guix Home

[Andrew Tropin]

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

On 2021-10-03 12:50, Liliana Marie Prikler wrote:

> Hi Guix,
>
> it's been a while since the discussion of whether or not to collect
> multiple profiles into a single directory [1].  This suggestion takes
> inspiration from that, but goes a vastly different route.  Instead of
> using environment variables to control Guix, it takes advantage of the
> recently added Guix Home, even if it is still a technical preview.
>
> So, what's the proposition?  I suggest we modify home-profile-service-
> type (or add a new service) such that it takes a list of <home-profile> 
> records instead of a list of packages.  This record would be defined as
>
>   (define-record-type* <home-profile> home-profile
>     make-home-profile home-profile? this-home-profile
>     (location home-profile-location) ; string, e.g. $HOME/.guix-profile
>     (short-name home-profile-short-name) ; string or #f, if given
>                                          ; construct a symlink in
>                                          ; /var/guix/.../per-user/
>     (manifest %home-profile-manifest) ; <manifest> or #f
>     (packages home-profile-packages) ; list of <package> or #f
>                                      ; fallback for manifest
>     (enabled? home-profile-enabled?) ; boolean, default #t
>     [...])
>
>   (define (home-profile-manifest home-profile)
>     (or (%home-profile-manifest home-profile)
>         (and=> (home-profile-packages home-profile) 
>                packages->manifest))))
>
> 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).  
>
> Some existing home services would need to be adapted towards this
> multiple profile usage.  For instance, home-fontconfig-service-type
> would need to accept a list of directories, rather than hardcode its
> value.
>
> What do y'all think?
>
> <https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html>
>
>

The discussion seems too heated and bloated, it's hard to reasonably
address arguments mentioned around, so I'll just post some thoughts and
a possible way to somehow proceed.

I suggest to split the bigger idea into smaller pieces, play with the
implementation locally/in fork/branch and see how it goes:

1. home-profiles-paths-service-type.  It will allow to add code for
sourcing profiles in setup-environment script and thus implement
workflows with multiple profiles.  Such profiles can be managed
externally or in the future built as a part of home environment.

2. home-[additional-]profiles-service-type.  It will allow to build
profiles from list of packages, optionally add a profile to
home-profiles-paths.  It will make ~/.guix-home/profiles/{emacs,web,etc}

To make it possible for other service to utilize multiple profiles, this
service will be extandable with values like that:

`((default . ,(list curl wget))
  (web . ,(list browser-ad-block-plugin))
  (emacs . ,(list emacs emacs-cider emacs-modus-themes)))

3. Maybe migrate ~/.guix-home/profile to ~/.guix-home/profiles/default.
  
I still can see a lot of potential problems related to search paths,
however part of them can be solved by duplicating packages in different
profiles or using dummy packages like emacs-consumer:
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/packages/emacs.scm#L56

Also, I can see potential complication of Guix Home in general due to
multiple profiles capabilities and I still not sure that it worth the
benefits mentioned below:

I agree that multiple profiles can be benifitial for both better package
organization/structuring needs and faster build/reconfigure times.

I also see some demand from people requesting such a feature.

Liliana, if you still into it, I suggest to start with something
similiar to what I described above, share the draft implementation and
intermediate results/impression in a separate thread and continue the
further discussion.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Hi,

Am Montag, dem 23.05.2022 um 16:14 +0300 schrieb Andrew Tropin:
> The discussion seems too heated and bloated, it's hard to reasonably
> address arguments mentioned around, so I'll just post some thoughts
> and a possible way to somehow proceed.
> 
> I suggest to split the bigger idea into smaller pieces, play with the
> implementation locally/in fork/branch and see how it goes:
> 
> 1. home-profiles-paths-service-type.  It will allow to add code for
> sourcing profiles in setup-environment script and thus implement
> workflows with multiple profiles.  Such profiles can be managed
> externally or in the future built as a part of home environment.
How about home-profile-loader-service-type as a name instead?  That
would imply that it's purpose is to load profiles.

> 2. home-[additional-]profiles-service-type.  It will allow to build
> profiles from list of packages, optionally add a profile to
> home-profiles-paths.  It will make ~/.guix-
> home/profiles/{emacs,web,etc}
> 
> To make it possible for other service to utilize multiple profiles,
> this service will be extandable with values like that:
> 
> `((default . ,(list curl wget))
>   (web . ,(list browser-ad-block-plugin))
>   (emacs . ,(list emacs emacs-cider emacs-modus-themes)))
I don't think I agree with this choice.  To satisfy both my own use
case of serving profiles in different locations from another and
another issue being raised w.r.t. configuring the location of the
.guix-home profile, I think we should make a triple of location,
optional short name, and manifest (which may be generated from packages
implicitly).  WDYT?

> 3. Maybe migrate ~/.guix-home/profile to ~/.guix-
> home/profiles/default.
Kinda agree, but with the caveat in (2).  Uniformity or chaos should be
a user choice :)

> I still can see a lot of potential problems related to search paths,
> however part of them can be solved by duplicating packages in
> different profiles or using dummy packages like emacs-consumer:
> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/packages/emacs.scm#L56
Or by making search paths first class in manifests, as also discussed
elsewhere.

> [...]
> Liliana, if you still into it, I suggest to start with something
> similiar to what I described above, share the draft implementation
> and intermediate results/impression in a separate thread and continue
> the further discussion.
Considering the above, I think a rough roadmap would be:
1. Implementing home-profiles-service-type (to build the profiles)
2. Implementing home-profile-loader-service-type
3. ???
4. Deprecate the existing home-profile-service-type in favor of the new
profile service type pair and/or implement it in terms of it.
where (1) and (2) could be done by two people/teams in parallel.

Given that the task has been simplified, I think I might start coding
on it, but I can't promise any particular deadline.  At the moment,
both my day job and review work delay any other contributions towards
Guix.

Cheers

Re: Multiple profiles with Guix Home

[Andrew Tropin]

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

On 2022-05-23 19:05, Liliana Marie Prikler wrote:

> Hi,
>
> Am Montag, dem 23.05.2022 um 16:14 +0300 schrieb Andrew Tropin:
>> The discussion seems too heated and bloated, it's hard to reasonably
>> address arguments mentioned around, so I'll just post some thoughts
>> and a possible way to somehow proceed.
>> 
>> I suggest to split the bigger idea into smaller pieces, play with the
>> implementation locally/in fork/branch and see how it goes:
>> 
>> 1. home-profiles-paths-service-type.  It will allow to add code for
>> sourcing profiles in setup-environment script and thus implement
>> workflows with multiple profiles.  Such profiles can be managed
>> externally or in the future built as a part of home environment.
> How about home-profile-loader-service-type as a name instead?  That
> would imply that it's purpose is to load profiles.

Looks ok for me.

>> 2. home-[additional-]profiles-service-type.  It will allow to build
>> profiles from list of packages, optionally add a profile to
>> home-profiles-paths.  It will make ~/.guix-
>> home/profiles/{emacs,web,etc}
>> 
>> To make it possible for other service to utilize multiple profiles,
>> this service will be extandable with values like that:
>> 
>> `((default . ,(list curl wget))
>>   (web . ,(list browser-ad-block-plugin))
>>   (emacs . ,(list emacs emacs-cider emacs-modus-themes)))
> I don't think I agree with this choice.  To satisfy both my own use
> case of serving profiles in different locations from another and
> another issue being raised w.r.t. configuring the location of the
> .guix-home profile, I think we should make a triple of location,
> optional short name, and manifest (which may be generated from packages
> implicitly).  WDYT?
>

This service is intended for profiles managed by Guix Home, so every
profile MUST be a part of home-environment (~/.guix-home is a symlink to
it).  I don't see any meaningful reasons to make it possible to
customize the path inside home-environment.

If you want to have profiles like ~/work/my-project/guix-profile or
~/.guix/profiles/my-python-environment managed by Guix Home you can
implement home-external-profiles-service-type, which can extended
activation service or any other impure tricks, but I would advice
against it.  I suggest either manage a profile with
home-[additional-]-profiles or manage them externally and load with
home-profile-paths/home-profile-loader.

>> 3. Maybe migrate ~/.guix-home/profile to ~/.guix-
>> home/profiles/default.
> Kinda agree, but with the caveat in (2).  Uniformity or chaos should be
> a user choice :)
>
>> I still can see a lot of potential problems related to search paths,
>> however part of them can be solved by duplicating packages in
>> different profiles or using dummy packages like emacs-consumer:
>> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/packages/emacs.scm#L56
> Or by making search paths first class in manifests, as also discussed
> elsewhere.
>
>> [...]
>> Liliana, if you still into it, I suggest to start with something
>> similiar to what I described above, share the draft implementation
>> and intermediate results/impression in a separate thread and continue
>> the further discussion.
> Considering the above, I think a rough roadmap would be:
> 1. Implementing home-profiles-service-type (to build the profiles)
> 2. Implementing home-profile-loader-service-type

This one looks simplier and also independent from #1, so I would
recommend to start with it.  Also, it's very likely that
home-profiles-service-type will be extending
home-profile-loader-service-type

> 3. ???
> 4. Deprecate the existing home-profile-service-type in favor of the new
> profile service type pair and/or implement it in terms of it.
> where (1) and (2) could be done by two people/teams in parallel.

The migration should be quite simple here.

JFYI: The design of Guix Home is flexible, essential services can be
completely customized, even symlink-manager can be removed or
substituted with something else (for example to make a read-only home
workflow proposed by Julien Lepiller in guix-home-manager).  This is
also used in rde to substitute home-shell-profile-service-type with
alternative implementation:
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features.scm#L234

This way you can experiment with multi-profile approach even without
modifying existing code.

>
> Given that the task has been simplified, I think I might start coding
> on it, but I can't promise any particular deadline.  At the moment,
> both my day job and review work delay any other contributions towards
> Guix.
>
> Cheers

I also advice to treat it as an experiment.  IMO Guix Home should be
relatively conservative, stable and simple.  Other advanced workflows
in most cases should be implemented and maintained separately and be
optionally pluggable in Guix Home by overriding essential services or
any other way.  In cases such workflows demonstrates their benifits
without compromising simplicity, they can be included.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Hi,

Am Dienstag, dem 24.05.2022 um 14:55 +0300 schrieb Andrew Tropin:
> On 2022-05-23 19:05, Liliana Marie Prikler wrote:
> > [...]
> > I don't think I agree with this choice.  To satisfy both my own use
> > case of serving profiles in different locations from another and
> > another issue being raised w.r.t. configuring the location of the
> > .guix-home profile, I think we should make a triple of location,
> > optional short name, and manifest (which may be generated from
> > packages implicitly).  WDYT?
> > 
> 
> This service is intended for profiles managed by Guix Home, so every
> profile MUST be a part of home-environment (~/.guix-home is a symlink
> to it).  I don't see any meaningful reasons to make it possible to
> customize the path inside home-environment.
Why though?  The decision to restrict Guix Home to dotfiles was already
a bad one that has since been overturned, so I think we should
carefully evaluate why "~/.guix-home" even is special.  In my point of
view, any path that is prefixed with the user's home ought to be fair
game, as should be constructing intermediate per-user profile symlinks
in /var/guix.

> If you want to have profiles like ~/work/my-project/guix-profile or
> ~/.guix/profiles/my-python-environment managed by Guix Home you can
> implement home-external-profiles-service-type, which can extended
> activation service or any other impure tricks, but I would advice
> against it.  I suggest either manage a profile with
> home-[additional-]-profiles or manage them externally and load with
> home-profile-paths/home-profile-loader.
Pardon me if I was confusing, but I meant to have one service defining
the existence of ~/work/my-project/guix-profile (that being home-
profiles-service-type) and another to load it (that being home-profile-
loader-service-type).  Admittedly, the existing way of specifying a
profile that is loaded becomes more work then, so perhaps we can add
some syntactic sugar to that, so that both services get extended at
once.

> > Considering the above, I think a rough roadmap would be:
> > 1. Implementing home-profiles-service-type (to build the profiles)
> > 2. Implementing home-profile-loader-service-type
> 
> This one looks simplier and also independent from #1, so I would
> recommend to start with it.  Also, it's very likely that
> home-profiles-service-type will be extending
> home-profile-loader-service-type
I thought about it for some while, but I really don't think either is
easier than the other, particularly in the way I described it, where
home-profiles-service-type and home-profile-loader-service-type are
orthogonal to each other.

> > 3. ???
> > 4. Deprecate the existing home-profile-service-type in favor of the
> > new profile service type pair and/or implement it in terms of it.
> > where (1) and (2) could be done by two people/teams in parallel.
> 
> The migration should be quite simple here.
> 
> JFYI: The design of Guix Home is flexible, essential services can be
> completely customized, even symlink-manager can be removed or
> substituted with something else (for example to make a read-only home
> workflow proposed by Julien Lepiller in guix-home-manager).  This is
> also used in rde to substitute home-shell-profile-service-type with
> alternative implementation:
> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features.scm#L234
I'm not sure if I'm that fond of this design choice – it reminds me a
bit about OOP horrors I was forced to learn.  Anyway, I don't think
it's relevant, as...

> This way you can experiment with multi-profile approach even without
> modifying existing code.
I was planning to run guix home from checkout with $HOME in /tmp anyway
for testing purposes.

> > Given that the task has been simplified, I think I might start
> > coding on it, but I can't promise any particular deadline.  At the
> > moments both my day job and review work delay any other
> > contributions towards Guix.
> > 
> > Cheers
> 
> I also advice to treat it as an experiment.  IMO Guix Home should be
> relatively conservative, stable and simple.  Other advanced workflows
> in most cases should be implemented and maintained separately and be
> optionally pluggable in Guix Home by overriding essential services or
> any other way.  In cases such workflows demonstrates their benifits
> without compromising simplicity, they can be included.
I initially planned for the new stuff to be backwards compatible by way
of sanitizers.  That probably still works for the design we have
currently, though YMMV.

Cheers

Re: Multiple profiles with Guix Home

[Andrew Tropin]

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

On 2022-05-24 20:31, Liliana Marie Prikler wrote:

> Hi,
>
> Am Dienstag, dem 24.05.2022 um 14:55 +0300 schrieb Andrew Tropin:
>> On 2022-05-23 19:05, Liliana Marie Prikler wrote:
>> > [...]
>> > I don't think I agree with this choice.  To satisfy both my own use
>> > case of serving profiles in different locations from another and
>> > another issue being raised w.r.t. configuring the location of the
>> > .guix-home profile, I think we should make a triple of location,
>> > optional short name, and manifest (which may be generated from
>> > packages implicitly).  WDYT?
>> > 
>> 
>> This service is intended for profiles managed by Guix Home, so every
>> profile MUST be a part of home-environment (~/.guix-home is a symlink
>> to it).  I don't see any meaningful reasons to make it possible to
>> customize the path inside home-environment.
> Why though?  The decision to restrict Guix Home to dotfiles was already
> a bad one that has since been overturned, so I think we should
> carefully evaluate why "~/.guix-home" even is special.  In my point of
> view, any path that is prefixed with the user's home ought to be fair
> game, as should be constructing intermediate per-user profile symlinks
> in /var/guix.

It's not bad, it had and has its own goals, pros and cons, I found
another design descision, which we think is more intuitive, but still
partially serving original goals and we switched to it.  The disucssion
about ~/.guix-home symlink itself is unrelated to both "dotfiles
question" and my original statement.

All dot/xdg/other files belong to home-environment and no side-effects
are done during the build of home-environment, the only side-effects
happens during activation and $HOME touched only by symlink-manager and
I would like to keep it to be the case, otherwise we will end up with
tons of stateful ad-hoc hacks.

That said, I would like to avoid any Guix Home logic to rely on paths
outside of home-environment.  In case you really need
~/work/my-project/guix-profile to be created for some reason you can
extend home-files-service-type and rely on symlink-manager to do this
dirty job, but the setup-environment script will still source
home-environment/profiles/your-profile-name and won't know anything
about ~/work/my-project/guix-profile.

>> If you want to have profiles like ~/work/my-project/guix-profile or
>> ~/.guix/profiles/my-python-environment managed by Guix Home you can
>> implement home-external-profiles-service-type, which can extended
>> activation service or any other impure tricks, but I would advice
>> against it.  I suggest either manage a profile with
>> home-[additional-]-profiles or manage them externally and load with
>> home-profile-paths/home-profile-loader.
> Pardon me if I was confusing, but I meant to have one service defining
> the existence of ~/work/my-project/guix-profile (that being home-
> profiles-service-type) and another to load it (that being home-profile-
> loader-service-type).  Admittedly, the existing way of specifying a
> profile that is loaded becomes more work then, so perhaps we can add
> some syntactic sugar to that, so that both services get extended at
> once.
>
>> > Considering the above, I think a rough roadmap would be:
>> > 1. Implementing home-profiles-service-type (to build the profiles)
>> > 2. Implementing home-profile-loader-service-type
>> 
>> This one looks simplier and also independent from #1, so I would
>> recommend to start with it.  Also, it's very likely that
>> home-profiles-service-type will be extending
>> home-profile-loader-service-type
> I thought about it for some while, but I really don't think either is
> easier than the other, particularly in the way I described it, where
> home-profiles-service-type and home-profile-loader-service-type are
> orthogonal to each other.
>
>> > 3. ???
>> > 4. Deprecate the existing home-profile-service-type in favor of the
>> > new profile service type pair and/or implement it in terms of it.
>> > where (1) and (2) could be done by two people/teams in parallel.
>> 
>> The migration should be quite simple here.
>> 
>> JFYI: The design of Guix Home is flexible, essential services can be
>> completely customized, even symlink-manager can be removed or
>> substituted with something else (for example to make a read-only home
>> workflow proposed by Julien Lepiller in guix-home-manager).  This is
>> also used in rde to substitute home-shell-profile-service-type with
>> alternative implementation:
>> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features.scm#L234
> I'm not sure if I'm that fond of this design choice – it reminds me a
> bit about OOP horrors I was forced to learn.  Anyway, I don't think
> it's relevant, as...
>> This way you can experiment with multi-profile approach even without
>> modifying existing code.
> I was planning to run guix home from checkout with $HOME in /tmp anyway
> for testing purposes.
>
>> > Given that the task has been simplified, I think I might start
>> > coding on it, but I can't promise any particular deadline.  At the
>> > moments both my day job and review work delay any other
>> > contributions towards Guix.
>> > 
>> > Cheers
>> 
>> I also advice to treat it as an experiment.  IMO Guix Home should be
>> relatively conservative, stable and simple.  Other advanced workflows
>> in most cases should be implemented and maintained separately and be
>> optionally pluggable in Guix Home by overriding essential services or
>> any other way.  In cases such workflows demonstrates their benifits
>> without compromising simplicity, they can be included.
> I initially planned for the new stuff to be backwards compatible by way
> of sanitizers.  That probably still works for the design we have
> currently, though YMMV.

Let's get some initial implementation done and will continue the
discussion on more real-life examples.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 25.05.2022 um 14:01 +0300 schrieb Andrew Tropin:
> On 2022-05-24 20:31, Liliana Marie Prikler wrote:
> 
> > Hi,
> > 
> > Am Dienstag, dem 24.05.2022 um 14:55 +0300 schrieb Andrew Tropin:
> > 
> > > On 2022-05-23 19:05, Liliana Marie Prikler wrote:
> > > > [...]
> > > > I don't think I agree with this choice.  To satisfy both my own
> > > > use case of serving profiles in different locations from
> > > > another and another issue being raised w.r.t. configuring the
> > > > location of the .guix-home profile, I think we should make a
> > > > triple of location, optional short name, and manifest (which
> > > > may be generated from packages implicitly).  WDYT?
> > > > 
> > > 
> > > This service is intended for profiles managed by Guix Home, so
> > > every profile MUST be a part of home-environment (~/.guix-home is
> > > a symlink to it).  I don't see any meaningful reasons to make it
> > > possible to customize the path inside home-environment.
> > Why though?  The decision to restrict Guix Home to dotfiles was
> > already a bad one that has since been overturned, so I think we
> > should carefully evaluate why "~/.guix-home" even is special.  In
> > my point of view, any path that is prefixed with the user's home
> > ought to be fair game, as should be constructing intermediate per-
> > user profile symlinks in /var/guix.
> 
> It's not bad, it had and has its own goals, pros and cons, I found
> another design descision, which we think is more intuitive, but still
> partially serving original goals and we switched to it.  The
> disucssion about ~/.guix-home symlink itself is unrelated to both
> "dotfiles question" and my original statement.
Perhaps it's only tangentially related, but it highlights a point of
contention that I have with Guix Home overall, being that it takes a
few very idiosyncratic "shortcuts", that I don't think make too much
sense in the wider sense of Guix.  Consider %profile-directory, for
example.  I can't see it anywhere in the code for Guix Home, so I
assume generations are currently littered into the user home.  The
specific choice of moving ~/.guix-profile to ~/.guix-home is another.
Assume I only want to use Guix Home for one or two config files, well
nope you can't unless you're willing to move you packages as well or
willing to have a pointless symlink that you didn't ask for.

Don't get me wrong, this is still mostly about managing multiple
profiles with Guix Home, but the way I see it, Guix Home's own profile
management could also be improved.

> All dot/xdg/other files belong to home-environment and no side-
> effects are done during the build of home-environment, the only side-
> effects happens during activation and $HOME touched only by symlink-
> manager and I would like to keep it to be the case, otherwise we will
> end up with tons of stateful ad-hoc hacks.
I struggle to see how my proposal would complicate that other than
adding more jobs to symlink manager (perhaps?).  For what it's worth, I
do think that job could be much simplified too by storing the symlinks
in an association list
(("~/path/to/symlink" "/gnu/store/path/to/target") ...),
which could be part of a Guix Home "profile" just like manifest.scm is
part of a normal Guix profile.  The activation script would then read
this table, expand "~" (as well as check that it is the first letter i
each of the first paths) and create the symlinks according to spec. 
Best of all, it doesn't even matter that much if the target is in the
store, in /var/guix/profiles/per-user, or even another place relative
to ~.  

Note that I believe that at the point of writing this file variables
such as $XDG_CONFIG_HOME should already have been resolved relative to
$HOME, with the former being specified in home-configuration or
assuming their usual defaults.  YMMV on whether that's actually useful,
one could alternatively allow $XDG_CONFIG_HOME/ etc. as leading
sequences too, though that invites more errors when experimenting with
homeless shelters outside of clean shells.

> That said, I would like to avoid any Guix Home logic to rely on paths
> outside of home-environment.  In case you really need
> ~/work/my-project/guix-profile to be created for some reason you can
> extend home-files-service-type and rely on symlink-manager to do this
> dirty job, but the setup-environment script will still source
> home-environment/profiles/your-profile-name and won't know anything
> about ~/work/my-project/guix-profile.
Sounds dirty.

> > 
> > 
> > > 
Cheers

Re: Multiple profiles with Guix Home

[andrew]

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

On 2022-05-26 01:36, Liliana Marie Prikler wrote:

> Hi,
>
> Am Mittwoch, dem 25.05.2022 um 14:01 +0300 schrieb Andrew Tropin:
>> On 2022-05-24 20:31, Liliana Marie Prikler wrote:
>> 
>> > Hi,
>> > 
>> > Am Dienstag, dem 24.05.2022 um 14:55 +0300 schrieb Andrew Tropin:
>> > 
>> > > On 2022-05-23 19:05, Liliana Marie Prikler wrote:
>> > > > [...]
>> > > > I don't think I agree with this choice.  To satisfy both my own
>> > > > use case of serving profiles in different locations from
>> > > > another and another issue being raised w.r.t. configuring the
>> > > > location of the .guix-home profile, I think we should make a
>> > > > triple of location, optional short name, and manifest (which
>> > > > may be generated from packages implicitly).  WDYT?
>> > > > 
>> > > 
>> > > This service is intended for profiles managed by Guix Home, so
>> > > every profile MUST be a part of home-environment (~/.guix-home is
>> > > a symlink to it).  I don't see any meaningful reasons to make it
>> > > possible to customize the path inside home-environment.
>> > Why though?  The decision to restrict Guix Home to dotfiles was
>> > already a bad one that has since been overturned, so I think we
>> > should carefully evaluate why "~/.guix-home" even is special.  In
>> > my point of view, any path that is prefixed with the user's home
>> > ought to be fair game, as should be constructing intermediate per-
>> > user profile symlinks in /var/guix.
>> 
>> It's not bad, it had and has its own goals, pros and cons, I found
>> another design descision, which we think is more intuitive, but still
>> partially serving original goals and we switched to it.  The
>> disucssion about ~/.guix-home symlink itself is unrelated to both
>> "dotfiles question" and my original statement.
> Perhaps it's only tangentially related, but it highlights a point of
> contention that I have with Guix Home overall, being that it takes a
> few very idiosyncratic "shortcuts", that I don't think make too much
> sense in the wider sense of Guix.  Consider %profile-directory, for
> example.  I can't see it anywhere in the code for Guix Home, so I
> assume generations are currently littered into the user home.  The
> specific choice of moving ~/.guix-profile to ~/.guix-home is another.
> Assume I only want to use Guix Home for one or two config files, well
> nope you can't unless you're willing to move you packages as well or
> willing to have a pointless symlink that you didn't ask for.

~/.guix-profile is independent from ~/.guix-home and you don't need to
move all the packages to Guix Home if you don't want it.

The profile management is the same as for Guix System.

~/.guix-home is a synonym to /run/current-system.

Customization of ~/.guix-home location is potentially troublesome and
was removed in October 2021.

>
> Don't get me wrong, this is still mostly about managing multiple
> profiles with Guix Home, but the way I see it, Guix Home's own profile
> management could also be improved.
>
>> All dot/xdg/other files belong to home-environment and no side-
>> effects are done during the build of home-environment, the only side-
>> effects happens during activation and $HOME touched only by symlink-
>> manager and I would like to keep it to be the case, otherwise we will
>> end up with tons of stateful ad-hoc hacks.
> I struggle to see how my proposal would complicate that other than
> adding more jobs to symlink manager (perhaps?).  For what it's worth, I
> do think that job could be much simplified too by storing the symlinks
> in an association list
> (("~/path/to/symlink" "/gnu/store/path/to/target") ...),
> which could be part of a Guix Home "profile" just like manifest.scm is
> part of a normal Guix profile.  The activation script would then read
> this table, expand "~" (as well as check that it is the first letter i
> each of the first paths) and create the symlinks according to spec. 
> Best of all, it doesn't even matter that much if the target is in the
> store, in /var/guix/profiles/per-user, or even another place relative
> to ~.  

A little too abstract/general, let's see how it goes during
implementation.

>
> Note that I believe that at the point of writing this file variables
> such as $XDG_CONFIG_HOME should already have been resolved relative to
> $HOME, with the former being specified in home-configuration or
> assuming their usual defaults.  YMMV on whether that's actually useful,
> one could alternatively allow $XDG_CONFIG_HOME/ etc. as leading
> sequences too, though that invites more errors when experimenting with
> homeless shelters outside of clean shells.
>
>> That said, I would like to avoid any Guix Home logic to rely on paths
>> outside of home-environment.  In case you really need
>> ~/work/my-project/guix-profile to be created for some reason you can
>> extend home-files-service-type and rely on symlink-manager to do this
>> dirty job, but the setup-environment script will still source
>> home-environment/profiles/your-profile-name and won't know anything
>> about ~/work/my-project/guix-profile.
> Sounds dirty.
>
>> > 
>> > 
>> > > 
> Cheers

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Hi,

Am Freitag, dem 27.05.2022 um 15:52 +0300 schrieb andrew@trop.in:
> On 2022-05-26 01:36, Liliana Marie Prikler wrote:
> 
> > [...]
> > I can't see it anywhere in the code for Guix Home, so I
> > assume generations are currently littered into the user home.  The
> > specific choice of moving ~/.guix-profile to ~/.guix-home is
> > another.
> > Assume I only want to use Guix Home for one or two config files,
> > well nope you can't unless you're willing to move you packages as
> > well or willing to have a pointless symlink that you didn't ask
> > for.
> 
> ~/.guix-profile is independent from ~/.guix-home and you don't need
> to move all the packages to Guix Home if you don't want it.
That's not quite an answer to the point I'm making.  The point is that
whether I want to or not, Guix Home clutters $HOME with this directory.
Point taken, guix package does so too *by default*, but the -p switch
exists partly to change that.  Problem is, -p on its own also clutters
(viz the generations), unless you are careful enough to populate /var
with it, which isn't a nice design either.

> The profile management is the same as for Guix System.
> 
> ~/.guix-home is a synonym to /run/current-system.
> 
> Customization of ~/.guix-home location is potentially troublesome and
> was removed in October 2021.
/run is not /home, though; I don't think that analogy really works. 
Assuming we do need to hardcode the guix-home root for... reasons...
why can't we place that root somewhere where the user won't be bothered
by it?  For backwards compatibility, we could check whether ~/.guix-
home exists and symlink it to the home profile in /var/guix/per-user if
it does.

Cheers
> 

Re: Multiple profiles with Guix Home

[John Kehayias]

Hello Liliana and Guix-ers,

I like this idea as a more integrated way of using multiple profiles in Guix, which I think is a unique and powerful feature of Guix. Having more first class citizen support of profiles I think is long overdue. Thanks for the proposal!

I'm curious about what else we can then build into this service that might help some of the issues around multiple profiles that have come up before. At the very least it seems this would be a good building block for doing operations where otherwise you'd have to do a bit of looping over profiles (as suggested in the Cookbook, and I think many of us do on our own) like updating packages.

There are also some issues that have been raised before that I think this could help address, so here are a few that I've seen that could have some relevance here. Mostly around search-paths and environment variables that get tricky with multiple profiles active. Perhaps not all relevant, but I wanted to cross-reference some related (to me, at least) discussions around multiple profile support in Guix:

Recently, we discussed this in the context of some environment variables like XDG_DATA_DIRS, and the more elusive XDG_CONFIG_DIRS here https://issues.guix.gnu.org/50103  The issues is with search-paths and different profiles (e.g. needing a glib package to make sure XDG_DATA_DIRS gets updated). With a more integrated approach to multiple profiles, could this help with combined search-paths?

Older, with dbus: https://issues.guix.gnu.org/48538  Here there is a hardcoded default user profile lookup https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/xorg.scm#n851

Finally, I think this proposal subsumes the old discussion on https://issues.guix.gnu.org/20255  and I think would be more "canonical" with Guix Home now part of Guix.

Anyway, Guix Home does look like a good fit for better profile support and these related edge cases with profiles. I'll just summarize my current usage of profiles, which I think others do as well as it comes from the Cookbook. I have several profiles for different sets of packages, like "desktop," "emacs," and so on, with the default ~/.guix-profile being a testing ground or to quickly use something (temporarily or before moving into a profile). ~/.config/guix has a profiles directory to store each of these and a manifests directory to store the manifests for each. I use a simple bash loop to e.g. guix package for each profile to update with the manifest, or guix gc to clean up.

Hope this is helpful for this discussion,
John