bug#20255: 'search-paths' should respect both user and system profile.

[Leo Prikler <leo.prikler@student.tugraz.at>]

Am Freitag, den 25.06.2021, 22:37 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Alex Kost <alezost@gmail.com> writes:
> 
> > zimoun (2020-02-21 16:53 +0100) wrote:
> > 
> > > Dear,
> > > 
> > > What is the status of the bug#20255 [1]?
> > > It is old; the last activity seems back on 2015, November. So let
> > > resume.
> > > 
> > > The issue is, e.g.:
> > >  - perl installed into the system profile
> > >  - perl-xml-parser installed into an user profile
> > > Then "guix package --search-paths" does not set correctly
> > > XML::Parser.
> > > 
> > > 
> > > Fixes had been pushed: dedb17a and b2a7223 and cc3de1d.
> > > 
> > > The final fix is still missing. Because it is a controversial
> > > patch
> > > [2] :-) i.e., running 'guix' in '/etc/profile'; see these lines
> > > of the
> > > patch:
> > > 
> > > +  eval `/run/current-system/profile/bin/guix package \\
> > > +          -p /run/current-system/profile             \\
> > > +          -p \"$HOME/.guix-profile\" --search-paths`
> > > 
> > > 
> > > The friendly "protest" [3] is about turning these lines optional
> > > via
> > > an environment variable. I am not sure to follow where the
> > > discussion
> > > had been going then.
> > 
> > As for me, I am OK with any default setting as long as there is a
> > way to
> > change it.  I recall Ludovic proposed a patch that allowed to
> > customize
> > "/etc/profile" and I was happy about it, but he changed his mind on
> > that
> > patch so it was never committed.
> 
> Do you still have a vetted interest in the issue at hand?  This is a
> serious usability problem that's been in limbo for 6 years,
> apparently
> for reasons of purity (not wanting to run a command in /etc/profile).
> While I share the sentiment that /etc/profile would better be 'inert'
> or
> static, it seems we haven't been able to come up with a better
> solution
> than calling 'guix package --search-paths'.  Like Ludovic, I also
> don't
> find the idea of allowing users to override /etc/profile very
> appealing;
> even if undocumented, its mere presence in the operating-system field
> would be an invitation for problems.  An environment variable to
> disable
> such basic functionality also seems backward to me.
> 
> I would personally be in favor of committing the fix as-is.  If < 1 s
> of
> wasted time on boot is an issue, I suggest to look into GNU Shepherd
> to
> offset it; optimization opportunities should abound :-).
I think there is a solution, that works not only for the case of
disabling this unwanted feature, but also to add in support for
multiple profiles, i.e. if the user has more than just their .guix-
profile to load.

If we made this feature opt-in in that a user would first have to write
their profiles to $HOME/.config/guix/default-profiles or a similarly
named file in $HOME/.config/guix, we could simply not run the command
if the file doesn't exist, and if it exists run it using the profiles
in there.

Most users will likely have
--8<---------------cut here---------------start------------->8---
/home/myself/.guix-profile
/run/current-system/profile
--8<---------------cut here---------------end--------------->8---
in it, but you could also have
--8<---------------cut here---------------start------------->8---
/home/myself/.guix-extra-profiles/emacs
/home/myself/.guix-extra-profiles/hundreds-of-npm-packages
/home/myself/.guix-extra-profiles/rusty-rust
/home/myself/.guix-profile
/run/current-system/profile
--8<---------------cut here---------------end--------------->8---

Of course, having to type out /home/myself is somewhat weird, and the
last two lines are a bit of boilerplate, that one might want to avoid. 
We could alternatively make it so that an empty file means "use
$HOME/.guix-profile and /run/current-system/profile", such that those
are always sourced no matter what.  WDYT?

Regards,
Leo