'search-paths' should respect both user and system profile.

宋

宋文武 wrote on 4 Apr 2015 12:29

Recipients:(address . bug-guix@gnu.org)

Message-ID:877ftschjt.fsf@gmail.com

Currently, search-paths built only from packages in user's profile.As reported by Andy Wingo in #guix, when I have:  perl installed into system profile  perl-xml-parser installed into user profile  guix package --search-paths won't give a hint about PERL5LIB,so it's very likely end up with a broken XML::Parser.Another interesting fact is that we have both guile and guix insystem profile, but the guix modules isn't work out-of-the-boxon GuixSD.

Ludovic Courtès wrote on 4 Apr 2015 23:04

Recipients:(name . 宋文武)(address . iyzsong@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87fv8fip01.fsf@gnu.org

宋文武 <iyzsong@gmail.com> skribis:

Toggle quote (8 lines)

> Currently, search-paths built only from packages in user's profile.> As reported by Andy Wingo in #guix, when I have:> perl installed into system profile> perl-xml-parser installed into user profile> > guix package --search-paths won't give a hint about PERL5LIB,> so it's very likely end up with a broken XML::Parser.

Rather it ends up with no XML::Parser, no?
That said, I’m not sure how this could be improved. We could hard-codelookup in /run/current-system/profile/. OTOH that’s not different frominstalling perl in one profile, and perl-xml-parser in another(arbitrary) profile, which ‘guix package’ cannot be aware of.
WDYT?

Toggle quote (4 lines)

> Another interesting fact is that we have both guile and guix in> system profile, but the guix modules isn't work out-of-the-box> on GuixSD.

(But guix.el *does* work out of the box.)
For a start, what about augmenting /etc/profile:

Toggle diff (13 lines)diff --git a/gnu/system.scm b/gnu/system.scmindex 0d510b6..bcc4919 100644--- a/gnu/system.scm+++ b/gnu/system.scm@@ -447,6 +447,8 @@ export PATH=$HOME/.guix-profile/bin:/run/current-system/profile/bin export PATH=/run/setuid-programs:/run/current-system/profile/sbin:$PATH export MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man export INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info+export GUILE_LOAD_PATH=$HOME/share/guile/site/2.0:/run/current-system/profile/share/guile/site/2.0+export GUILE_LOAD_COMPILED_PATH=$HOME/share/guile/site/2.0:/run/current-system/profile/share/guile/site/2.0  export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share export XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg

Thanks, Ludo’.

宋

宋文武 wrote on 5 Apr 2015 05:39

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20255@debbugs.gnu.org)

Message-ID:87d23j1bxk.fsf@gmail.com

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (18 lines)> 宋文武 <iyzsong@gmail.com> skribis:>>> Currently, search-paths built only from packages in user's profile.>> As reported by Andy Wingo in #guix, when I have:>>   perl installed into system profile>>   perl-xml-parser installed into user profile>>   >> guix package --search-paths won't give a hint about PERL5LIB,>> so it's very likely end up with a broken XML::Parser.>> Rather it ends up with no XML::Parser, no?>> That said, I’m not sure how this could be improved.  We could hard-code> lookup in /run/current-system/profile/.  OTOH that’s not different from> installing perl in one profile, and perl-xml-parser in another> (arbitrary) profile, which ‘guix package’ cannot be aware of.>> WDYT?

As 'guix package' is for only one profile, that's fine.Since we can get search-paths from system profile using:  guix package -p /run/current-system/profile --search-paths
I think the missing is to check whether we are under GuixSD,and then merge those 2 search-paths object in scheme levelto get a full search-paths.
Or better to generate a 'profile' script for each manifest, and thenmerged in shell level, so it can work out-of-the-box. How about:  - /etc/profile:    # configuration for the whole system goes here.    # shouldn't refer profile paths.    export LANG=en_US.utf8    export SSL_CERT_DIR=/etc/ssl/certs    export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules    [...]
    source /run/current-system/profile/etc/profile
    if [ -f $HOME/.guix-profile/etc/profile ]; then      source $HOME/.guix-profile/etc/profile    fi
    # honor setuid-programs    export PATH=/run/setuid-programs:$PATH
  - /run/current-system/profile/etc/profile:    export PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH    export MANPATH=/run/current-system/profile/share/man:$PATH    [...]      - ~/.guix-profile/etc/profile:    export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH    [...]
The idea to generate profile from search-paths is not new,I heard it from you IIRC.I think it's the time to do it.

Ludovic Courtès wrote on 5 Apr 2015 20:15

Recipients:(name . 宋文武)(address . iyzsong@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:871tjyfnl8.fsf@gnu.org

宋文武 <iyzsong@gmail.com> skribis:

Toggle quote (4 lines)

> As 'guix package' is for only one profile, that's fine.> Since we can get search-paths from system profile using:> guix package -p /run/current-system/profile --search-paths

Right.

Toggle quote (36 lines)> I think the missing is to check whether we are under GuixSD,> and then merge those 2 search-paths object in scheme level> to get a full search-paths.>> Or better to generate a 'profile' script for each manifest, and then> merged in shell level, so it can work out-of-the-box. How about:>   - /etc/profile:>     # configuration for the whole system goes here.>     # shouldn't refer profile paths.>     export LANG=en_US.utf8>     export SSL_CERT_DIR=/etc/ssl/certs>     export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules>     [...]>>     source /run/current-system/profile/etc/profile>>     if [ -f $HOME/.guix-profile/etc/profile ]; then>       source $HOME/.guix-profile/etc/profile>     fi>>     # honor setuid-programs>     export PATH=/run/setuid-programs:$PATH>>   - /run/current-system/profile/etc/profile:>     export PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH>     export MANPATH=/run/current-system/profile/share/man:$PATH>     [...]>     >   - ~/.guix-profile/etc/profile:>     export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH>     [...]>> The idea to generate profile from search-paths is not new,> I heard it from you IIRC.> I think it's the time to do it.

Agreed, the plan makes sense and I think we have all the bits.
A related question is whether to encode search path environmentvariables into the manifest (currently they are “guessed” by looking atsame-named packages; see (guix build package).) I think that wouldprobably simplify things and make it easier to share this environmentvariable code.
Thoughts?
Thanks,Ludo’.

宋

宋文武 wrote on 6 Apr 2015 06:02

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20255@debbugs.gnu.org)

Message-ID:876199q4z1.fsf@gmail.com

Toggle quote (15 lines)> [...]>>>> The idea to generate profile from search-paths is not new,>> I heard it from you IIRC.>> I think it's the time to do it.>> Agreed, the plan makes sense and I think we have all the bits.>> A related question is whether to encode search path environment> variables into the manifest (currently they are “guessed” by looking at> same-named packages; see (guix build package).)  I think that would> probably simplify things and make it easier to share this environment> variable code.>> Thoughts?

I see, currently search-paths depends on the packages recipes. If weupdate the related scheme code, then search-paths got updated, even wedidn't touch packages in profile at all.  It's a little confusing.So I think we should encode the search-paths for each package inmanifest.

Toggle quote (2 lines)

> Thanks,> Ludo’.

Mark HWeaver wrote on 6 Apr 2015 10:24

Recipients:(name . 宋文武)(address . iyzsong@gmail.com)

Message-ID:87lhi5zmsp.fsf@netris.org

宋文武 <iyzsong@gmail.com> writes:

Toggle quote (21 lines)>> [...]>>>>>> The idea to generate profile from search-paths is not new,>>> I heard it from you IIRC.>>> I think it's the time to do it.>>>> Agreed, the plan makes sense and I think we have all the bits.>>>> A related question is whether to encode search path environment>> variables into the manifest (currently they are “guessed” by looking at>> same-named packages; see (guix build package).)  I think that would>> probably simplify things and make it easier to share this environment>> variable code.>>>> Thoughts?> I see, currently search-paths depends on the packages recipes. If we> update the related scheme code, then search-paths got updated, even we> didn't touch packages in profile at all.  It's a little confusing.> So I think we should encode the search-paths for each package in> manifest.

I agree.
Mark

Ludovic Courtès wrote on 3 May 2015 00:12

Recipients:(name . 宋文武)(address . iyzsong@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87ioca4ojo.fsf@gnu.org

宋文武 <iyzsong@gmail.com> skribis:

Toggle quote (21 lines)>> [...]>>>>>> The idea to generate profile from search-paths is not new,>>> I heard it from you IIRC.>>> I think it's the time to do it.>>>> Agreed, the plan makes sense and I think we have all the bits.>>>> A related question is whether to encode search path environment>> variables into the manifest (currently they are “guessed” by looking at>> same-named packages; see (guix build package).)  I think that would>> probably simplify things and make it easier to share this environment>> variable code.>>>> Thoughts?> I see, currently search-paths depends on the packages recipes. If we> update the related scheme code, then search-paths got updated, even we> didn't touch packages in profile at all.  It's a little confusing.> So I think we should encode the search-paths for each package in> manifest.

Done in dedb17a.
That will make it easier to generate environment variable settings.
Ludo’.

Ludovic Courtès wrote on 4 May 2015 23:44

Recipients:(name . 宋文武)(address . iyzsong@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87lhh43tn0.fsf@gnu.org

宋文武 <iyzsong@gmail.com> skribis:

Toggle quote (28 lines)> Or better to generate a 'profile' script for each manifest, and then> merged in shell level, so it can work out-of-the-box. How about:>   - /etc/profile:>     # configuration for the whole system goes here.>     # shouldn't refer profile paths.>     export LANG=en_US.utf8>     export SSL_CERT_DIR=/etc/ssl/certs>     export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules>     [...]>>     source /run/current-system/profile/etc/profile>>     if [ -f $HOME/.guix-profile/etc/profile ]; then>       source $HOME/.guix-profile/etc/profile>     fi>>     # honor setuid-programs>     export PATH=/run/setuid-programs:$PATH>>   - /run/current-system/profile/etc/profile:>     export PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH>     export MANPATH=/run/current-system/profile/share/man:$PATH>     [...]>     >   - ~/.guix-profile/etc/profile:>     export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH>     [...]

There’s a further complication here: ‘profile-derivation’, which buildsthe profile, doesn’t know its user-visible name ~/.guix-profile. Itjust knows its store file name. However, we don’t want etc/profile toread:
export PATH=/gnu/store/...-profile/bin:$PATH
because then, the user’s environment variables in a running sessionwould keep pointing to a given profile generation.
So we have to tell ‘profile-generation’ what the user-visible name ofthe profile is going to be. Attached is a very rough patch to do that.This is not so nice because all user interfaces will now have to passthat #:target parameter or etc/profile will be “wrong.”
Another option would be to simply run:
eval `guix package -p ~/.guix-profile --search-paths`
This has two downsides:
1. It takes ~200 ms to run on my laptop, which can maybe be noticeable; OTOH it’s only for interactive shells, so maybe that’s OK.
2. If there’s a manifest format change and /etc/profile calls a ‘guix’ command that cannot handle the manifest format (because it’s older than the ‘guix’ used to build the profile), then it doesn’t work at all (that’s a bit contrived, but not completely impossible.)
Thoughts?
Ludo’.

Modified guix/profiles.scm

Toggle diff (111 lines)diff --git a/guix/profiles.scm b/guix/profiles.scmindex 8445e00..308dc23 100644--- a/guix/profiles.scm+++ b/guix/profiles.scm@@ -582,10 +582,15 @@ MANIFEST.  Single-file bundles are required by programs such as Git and Lynx."  (define* (profile-derivation manifest                              #:key+                             target                              (hooks %default-profile-hooks))   "Return a derivation that builds a profile (aka. 'user environment') with the given MANIFEST.  The profile includes additional derivations returned by-the monadic procedures listed in HOOKS--such as an Info 'dir' file, etc."+the monadic procedures listed in HOOKS--such as an Info 'dir' file, etc.++When TARGET is not #f, it must be a string denoting the file name under which+the profile will be available--e.g., \"/home/rms/.guix-profile\".  This name+is used in the profile's 'etc/profile' file (read that again.)"   (mlet %store-monad ((extras (if (null? (manifest-entries manifest))                                   (return '())                                   (sequence %store-monad@@ -598,20 +603,72 @@ the monadic procedures listed in HOOKS--such as an Info 'dir' file, etc."      (define builder       #~(begin-          (use-modules (ice-9 pretty-print)-                       (guix build union))+          (use-modules (ice-9 match)+                       (ice-9 regex)+                       (ice-9 pretty-print)+                       (guix build union)+                       (guix build utils)+                       (guix search-paths))++          (define target+            '#$target)++          (define search-paths+            (map sexp->search-path-specification+                 '#$(map search-path-specification->sexp+                         (append-map manifest-entry-search-paths+                                     (manifest-entries manifest)))))++          (define (use-target value separator)+            (let ((items ((@@ (guix search-paths) string-tokenize*)+                          value separator)))+              (string-join (map (lambda (str)+                                  (string-append target+                                                 (string-drop str+                                                              (string-length+                                                               #$output))))+                                items)+                           separator)))++          (define write-environment-variable-definition+            (match-lambda+              ((spec . value)+               (let ((variable (search-path-specification-variable spec))+                     (sep      (search-path-specification-separator spec)))+                 (display+                  (environment-variable-definition variable+                                                   (if target+                                                       (use-target value sep)+                                                       value)+                                                   #:separator sep+                                                   #:kind 'prefix))+                 (newline)))))            (setvbuf (current-output-port) _IOLBF)           (setvbuf (current-error-port) _IOLBF) +          ;; Make the symlinks.           (union-build #$output '#$inputs                        #:log-port (%make-void-port "w"))++          ;; Store meta-data.           (call-with-output-file (string-append #$output "/manifest")             (lambda (p)-              (pretty-print '#$(manifest->gexp manifest) p)))))+              (pretty-print '#$(manifest->gexp manifest) p)))++          ;; Store a ready-to-use Bash profile.+          (mkdir-p (string-append #$output "/etc"))+          (with-output-to-file (string-append #$output "/etc/profile")+            (lambda ()+              (let ((variables (evaluate-search-paths search-paths #$output)))+                (for-each write-environment-variable-definition+                          variables))))))      (gexp->derivation "profile" builder-                      #:modules '((guix build union))+                      #:modules '((guix build union)+                                  (guix build utils)+                                  (guix search-paths)+                                  (guix records))                       #:local-build? #t)))  (define (profile-regexp profile)	Modified   guix/scripts/package.scmdiff --git a/guix/scripts/package.scm b/guix/scripts/package.scmindex 7f53af7..38ec8ed 100644--- a/guix/scripts/package.scm+++ b/guix/scripts/package.scm@@ -833,6 +833,7 @@ more information.~%"))                (let* ((prof-drv (run-with-store (%store)                                   (profile-derivation                                    new+                                   #:target (user-friendly-profile profile)                                    #:hooks (if bootstrap?                                                '()                                                %default-profile-hooks))))

宋

宋文武 wrote on 5 May 2015 10:28

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20255@debbugs.gnu.org)

Message-ID:87k2wnqvga.fsf@gmail.com

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (39 lines)> 宋文武 <iyzsong@gmail.com> skribis:>>> Or better to generate a 'profile' script for each manifest, and then>> merged in shell level, so it can work out-of-the-box. How about:>>   - /etc/profile:>>     # configuration for the whole system goes here.>>     # shouldn't refer profile paths.>>     export LANG=en_US.utf8>>     export SSL_CERT_DIR=/etc/ssl/certs>>     export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules>>     [...]>>>>     source /run/current-system/profile/etc/profile>>>>     if [ -f $HOME/.guix-profile/etc/profile ]; then>>       source $HOME/.guix-profile/etc/profile>>     fi>>>>     # honor setuid-programs>>     export PATH=/run/setuid-programs:$PATH>>>>   - /run/current-system/profile/etc/profile:>>     export PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH>>     export MANPATH=/run/current-system/profile/share/man:$PATH>>     [...]>>     >>   - ~/.guix-profile/etc/profile:>>     export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH>>     [...]>> There’s a further complication here: ‘profile-derivation’, which builds> the profile, doesn’t know its user-visible name ~/.guix-profile.  It> just knows its store file name.  However, we don’t want etc/profile to> read:>>   export PATH=/gnu/store/...-profile/bin:$PATH>> because then, the user’s environment variables in a running session> would keep pointing to a given profile generation.

Indeed.  Run guix to install a package should make it availableimmediately.  Currently, we have 'PATH=~/.guix-profile/bin' inprofile and print hint for additional variables.(Note that when profile changes, even we build all variables with thelocation they going to be, a hint or re-source is still needed when thenew profile bring new variables.)

Toggle quote (23 lines)>> So we have to tell ‘profile-generation’ what the user-visible name of> the profile is going to be.  Attached is a very rough patch to do that.> This is not so nice because all user interfaces will now have to pass> that #:target parameter or etc/profile will be “wrong.”>> Another option would be to simply run:>>   eval `guix package -p ~/.guix-profile --search-paths`>> This has two downsides:>>   1. It takes ~200 ms to run on my laptop, which can maybe be>      noticeable; OTOH it’s only for interactive shells, so maybe that’s>      OK.>>   2. If there’s a manifest format change and /etc/profile calls a ‘guix’>      command that cannot handle the manifest format (because it’s older>      than the ‘guix’ used to build the profile), then it doesn’t work at>      all (that’s a bit contrived, but not completely impossible.)>> Thoughts?>

How about using a shell variable as input for the location:(replace /gnu/store/xxx with $GUIX_PROFILE)
# etc/profile export PATH=$GUIX_PROFILE/bin:$PATH export MANPATH=$GUIX_PROFILE/share/man:$MANPATH ...
Then when 'source' it, we pass the location:(we did know where $GUIX_PROFILE is when do the 'source')
# ~/.bash_profile GUIX_PROFILE=$HOME/.guix-profile if [ -f $GUIX_PROFILE/etc/profile ]; then . $GUIX_PROFILE/etc/profile fi
# /etc/profile GUIX_PROFILE=/run/current-system/profile source $GUIX_PROFILE/etc/profile

Ludovic Courtès wrote on 5 May 2015 14:35

Recipients:(name . 宋文武)(address . iyzsong@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87h9rr5hje.fsf@gnu.org

宋文武 <iyzsong@gmail.com> skribis:

Toggle quote (21 lines)> How about using a shell variable as input for the location:> (replace /gnu/store/xxx with $GUIX_PROFILE)>>   # etc/profile>   export PATH=$GUIX_PROFILE/bin:$PATH>   export MANPATH=$GUIX_PROFILE/share/man:$MANPATH>   ...>> Then when 'source' it, we pass the location:> (we did know where $GUIX_PROFILE is when do the 'source')>>   # ~/.bash_profile>   GUIX_PROFILE=$HOME/.guix-profile>   if [ -f $GUIX_PROFILE/etc/profile ]; then>     . $GUIX_PROFILE/etc/profile>   fi>>   # /etc/profile>   GUIX_PROFILE=/run/current-system/profile>   source $GUIX_PROFILE/etc/profile

Yes, but we would also like users to be able to source~/.guix-profile/etc/profile themselves directly, and it wouldn’t be niceto ask them to set GUIX_PROFILE before sourcing it.
Ludo’.

Ludovic Courtès wrote on 6 May 2015 18:35

Recipients:(name . 宋文武)(address . iyzsong@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87fv79u0ik.fsf@gnu.org

宋文武 <iyzsong@gmail.com> skribis:

Toggle quote (21 lines)> How about using a shell variable as input for the location:> (replace /gnu/store/xxx with $GUIX_PROFILE)>>   # etc/profile>   export PATH=$GUIX_PROFILE/bin:$PATH>   export MANPATH=$GUIX_PROFILE/share/man:$MANPATH>   ...>> Then when 'source' it, we pass the location:> (we did know where $GUIX_PROFILE is when do the 'source')>>   # ~/.bash_profile>   GUIX_PROFILE=$HOME/.guix-profile>   if [ -f $GUIX_PROFILE/etc/profile ]; then>     . $GUIX_PROFILE/etc/profile>   fi>>   # /etc/profile>   GUIX_PROFILE=/run/current-system/profile>   source $GUIX_PROFILE/etc/profile

I ended up doing that in d664f1b. Please check d664f1b and d995942 andreport and issues/bugs.
Part of the initial problem you reported had to do with combiningprofiles (perl in one profile, perl-xml-parser in another.) This partis not addressed yet, and it turns out to be more common than Iinitially thought: consider for instance MANPATH (with man-db installedin the system profile and man pages in the user’s profile.)
Unfortunately the etc/profile files are not going to allow us to solvethat. ‘guix package --search-paths’ could do the actual combination,though.
Thanks,Ludo’.

Ludovic Courtès wrote on 12 Nov 2015 12:13

Recipients:(name . 宋文武)(address . iyzsong@gmail.com)

Message-ID:87y4e3zd00.fsf@gnu.org

Some progress has been made: fc2d233 allows search paths for multipleprofiles to be combined.
So I think I will eventually (‘guix-devel’ needs to be updated first)change /etc/profile to do:
eval `guix package -p /run/current-system/profile \ -p $HOME/.guix-profile --search-paths`
That should solve the combined profile issue.
This operation takes ~400ms on my machine. This would be a problem ifwe had to do it every time a shell is started, but here we only need todo it for log-in shells, which is rare enough.
WDYT?
Thanks,Ludo’.

Ludovic Courtès wrote on 19 Nov 2015 23:32

Recipients:(name . 宋文武)(address . iyzsong@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87lh9tvcws.fsf@gnu.org

ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (27 lines)> 宋文武 <iyzsong@gmail.com> skribis:>>>> [...]>>>>>>>> The idea to generate profile from search-paths is not new,>>>> I heard it from you IIRC.>>>> I think it's the time to do it.>>>>>> Agreed, the plan makes sense and I think we have all the bits.>>>>>> A related question is whether to encode search path environment>>> variables into the manifest (currently they are “guessed” by looking at>>> same-named packages; see (guix build package).)  I think that would>>> probably simplify things and make it easier to share this environment>>> variable code.>>>>>> Thoughts?>> I see, currently search-paths depends on the packages recipes. If we>> update the related scheme code, then search-paths got updated, even we>> didn't touch packages in profile at all.  It's a little confusing.>> So I think we should encode the search-paths for each package in>> manifest.>> Done in dedb17a.>> That will make it easier to generate environment variable settings.

Here’s the patch that does that, to try on b2a7223 or later.
Could you comment and give it a try? My main concern was the latencyintroduced at log-in shells, but it’s OK, at least on my i5+SSD laptop.

Toggle snippet (11 lines)

$ time guix package -p ~/.guix-profile -p /run/current-system/profile --search-paths > /dev/null
real 0m0.290suser 0m0.372ssys 0m0.028s$ guix package -I | wc -l215$ guix package -p /run/current-system/profile -I | wc -l43

I’ll push it soon if there are no objections.
TIA!
Ludo’.

Toggle diff (63 lines)diff --git a/gnu/system.scm b/gnu/system.scmindex 2755d85..7d1d33e 100644--- a/gnu/system.scm+++ b/gnu/system.scm@@ -429,35 +429,49 @@ export SSL_CERT_DIR=/etc/ssl/certs export SSL_CERT_FILE=\"$SSL_CERT_DIR/ca-certificates.crt\" export GIT_SSL_CAINFO=\"$SSL_CERT_FILE\" -# Crucial variables that could be missing in the profiles' 'etc/profile'-# because they would require combining both profiles.-# FIXME: See <http://bugs.gnu.org/20255>.-export MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man-export INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info+# Search paths for GLib schemas, GTK+ icons, and so on. export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share export XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg  # Ignore the default value of 'PATH'. unset PATH -# Load the system profile's settings.+if [ -x /run/current-system/profile/bin/guix ]+then+  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from the+  # profiles' individual 'etc/profile'.  Thus, combine both profiles when+  # computing the search paths.+  #+  # This may take a few hundred milliseconds, but it's OK because this is+  # performed for log-in shells only.+  eval `/run/current-system/profile/bin/guix package \\+          -p /run/current-system/profile             \\+          -p \"$HOME/.guix-profile\" --search-paths`+else+  # In the unlikely case that Guix is not in the global profile,+  # fall back to the simpler, yet less accurate method (see+  # <http://bugs.gnu.org/20255>.)   GUIX_PROFILE=/run/current-system/profile \\   . /run/current-system/profile/etc/profile -# Prepend setuid programs.-export PATH=/run/setuid-programs:$PATH-   if [ -f \"$HOME/.guix-profile/etc/profile\" ]   then     # Load the user profile's settings.     GUIX_PROFILE=\"$HOME/.guix-profile\" \\     . \"$HOME/.guix-profile/etc/profile\"-else+  fi+fi++if [ ! -f \"$HOME/.guix-profile\" ]+then   # At least define this one so that basic things just work   # when the user installs their first package.   export PATH=\"$HOME/.guix-profile/bin:$PATH\" fi +# Prepend setuid programs.+export PATH=/run/setuid-programs:$PATH+ # Append the directory of 'site-start.el' to the search path. export EMACSLOADPATH=:/etc/emacs

Alex Kost wrote on 20 Nov 2015 23:42

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87h9kguwc4.fsf@gmail.com

Ludovic Courtès (2015-11-20 01:32 +0300) wrote:

Toggle quote (13 lines)> -# Load the system profile's settings.> +if [ -x /run/current-system/profile/bin/guix ]> +then> +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from the> +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when> +  # computing the search paths.> +  #> +  # This may take a few hundred milliseconds, but it's OK because this is> +  # performed for log-in shells only.> +  eval `/run/current-system/profile/bin/guix package \\> +          -p /run/current-system/profile             \\> +          -p \"$HOME/.guix-profile\" --search-paths`

Sorry, but it's not OK for me.  As a user, I'm *strongly* againstrunning 'guix' (or any other program) in /etc/profile.  I would reallylike to have an option to avoid this.  Is it possible?
-- Thanks,Alex

Ludovic Courtès wrote on 21 Nov 2015 09:57

Recipients:(name . Alex Kost)(address . alezost@gmail.com)

Message-ID:87ziy7d90z.fsf@gnu.org

Alex Kost <alezost@gmail.com> skribis:

Toggle quote (18 lines)> Ludovic Courtès (2015-11-20 01:32 +0300) wrote:>>> -# Load the system profile's settings.>> +if [ -x /run/current-system/profile/bin/guix ]>> +then>> +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from the>> +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when>> +  # computing the search paths.>> +  #>> +  # This may take a few hundred milliseconds, but it's OK because this is>> +  # performed for log-in shells only.>> +  eval `/run/current-system/profile/bin/guix package \\>> +          -p /run/current-system/profile             \\>> +          -p \"$HOME/.guix-profile\" --search-paths`>> Sorry, but it's not OK for me.  As a user, I'm *strongly* against> running 'guix' (or any other program) in /etc/profile.

Why? (Honest question.)

Toggle quote (2 lines)

> I would really like to have an option to avoid this. Is it possible?

Not that I know of. Please read http://bugs.gnu.org/20255.
Ludo’.

Alex Kost wrote on 21 Nov 2015 19:41

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20255@debbugs.gnu.org)

Message-ID:874mgfkxee.fsf@gmail.com

Ludovic Courtès (2015-11-21 11:57 +0300) wrote:

Toggle quote (22 lines)> Alex Kost <alezost@gmail.com> skribis:>>> Ludovic Courtès (2015-11-20 01:32 +0300) wrote:>>>>> -# Load the system profile's settings.>>> +if [ -x /run/current-system/profile/bin/guix ]>>> +then>>> +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from the>>> +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when>>> +  # computing the search paths.>>> +  #>>> +  # This may take a few hundred milliseconds, but it's OK because this is>>> +  # performed for log-in shells only.>>> +  eval `/run/current-system/profile/bin/guix package \\>>> +          -p /run/current-system/profile             \\>>> +          -p \"$HOME/.guix-profile\" --search-paths`>>>> Sorry, but it's not OK for me.  As a user, I'm *strongly* against>> running 'guix' (or any other program) in /etc/profile.>> Why?  (Honest question.)

At first, because of the slowdown: it may be a few hundred millisecondsfor you, but it's several seconds for me. But actually, even if it wasseveral milliseconds, I still wouldn't like it, as (IMHO) /etc/profileshould only set variables, and not run external programs.

Toggle quote (4 lines)

>> I would really like to have an option to avoid this. Is it possible?>> Not that I know of. Please read <http://bugs.gnu.org/20255>.

What about making some environment variable which will be honored by'operating-system-etc-service' procedure. So depending on this variablethat 'eval ...' command will or will not be added to "/etc/profile"during 'guix system ...' process.
For example, when I do:
GUIX_IGNORE_SYSTEM_PROFILE_ENV=1 guix system build my-config.scm
the "etc/profile" of the built system will not contain those 'eval ...'lines. WDYT?
-- Alex

Ludovic Courtès wrote on 21 Nov 2015 21:10

Recipients:(name . Alex Kost)(address . alezost@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87wptb5d1y.fsf@gnu.org

Alex Kost <alezost@gmail.com> skribis:

Toggle quote (27 lines)> Ludovic Courtès (2015-11-21 11:57 +0300) wrote:>>> Alex Kost <alezost@gmail.com> skribis:>>>>> Ludovic Courtès (2015-11-20 01:32 +0300) wrote:>>>>>>> -# Load the system profile's settings.>>>> +if [ -x /run/current-system/profile/bin/guix ]>>>> +then>>>> +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from the>>>> +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when>>>> +  # computing the search paths.>>>> +  #>>>> +  # This may take a few hundred milliseconds, but it's OK because this is>>>> +  # performed for log-in shells only.>>>> +  eval `/run/current-system/profile/bin/guix package \\>>>> +          -p /run/current-system/profile             \\>>>> +          -p \"$HOME/.guix-profile\" --search-paths`>>>>>> Sorry, but it's not OK for me.  As a user, I'm *strongly* against>>> running 'guix' (or any other program) in /etc/profile.>>>> Why?  (Honest question.)>> At first, because of the slowdown: it may be a few hundred milliseconds> for you, but it's several seconds for me.

Really? Can you show the output of:
time guix package -p /run/current-system/profile \ -p ~/.guix-profile --search-paths
?

Toggle quote (4 lines)

> But actually, even if it was several milliseconds, I still wouldn't> like it, as (IMHO) /etc/profile should only set variables, and not run> external programs.

I don’t buy this “principle”: /etc/profile is a program, and the outputof --search-paths is trusted to contain only environment variablesetting.
In the discussion of this bug, we tried hard to avoid resorting toinvoking a program, but ultimately no other solution came out.

Toggle quote (16 lines)>>> I would really like to have an option to avoid this.  Is it possible?>>>> Not that I know of.  Please read <http://bugs.gnu.org/20255>.>> What about making some environment variable which will be honored by> 'operating-system-etc-service' procedure.  So depending on this variable> that 'eval ...' command will or will not be added to "/etc/profile"> during 'guix system ...' process.>> For example, when I do:>>   GUIX_IGNORE_SYSTEM_PROFILE_ENV=1 guix system build my-config.scm>> the "etc/profile" of the built system will not contain those 'eval ...'> lines.  WDYT?

This would be unreasonable.  We’re talking about a basic feature here.If basic features are broken to the point that we prefer to offer waysto bypass them, and have a semi-broken system, then there’s a problem,IMO.
Ludo’.

Alex Kost wrote on 22 Nov 2015 08:52

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20255@debbugs.gnu.org)

Message-ID:87r3jisc76.fsf@gmail.com

Ludovic Courtès (2015-11-21 23:10 +0300) wrote:

Toggle quote (34 lines)> Alex Kost <alezost@gmail.com> skribis:>>> Ludovic Courtès (2015-11-21 11:57 +0300) wrote:>>>>> Alex Kost <alezost@gmail.com> skribis:>>>>>>> Ludovic Courtès (2015-11-20 01:32 +0300) wrote:>>>>>>>>> -# Load the system profile's settings.>>>>> +if [ -x /run/current-system/profile/bin/guix ]>>>>> +then>>>>> +  # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from the>>>>> +  # profiles' individual 'etc/profile'.  Thus, combine both profiles when>>>>> +  # computing the search paths.>>>>> +  #>>>>> +  # This may take a few hundred milliseconds, but it's OK because this is>>>>> +  # performed for log-in shells only.>>>>> +  eval `/run/current-system/profile/bin/guix package \\>>>>> +          -p /run/current-system/profile             \\>>>>> +          -p \"$HOME/.guix-profile\" --search-paths`>>>>>>>> Sorry, but it's not OK for me.  As a user, I'm *strongly* against>>>> running 'guix' (or any other program) in /etc/profile.>>>>>> Why?  (Honest question.)>>>> At first, because of the slowdown: it may be a few hundred milliseconds>> for you, but it's several seconds for me.>> Really?  Can you show the output of:>>   time guix package -p /run/current-system/profile \>                     -p ~/.guix-profile --search-paths

real 0m2.634suser 0m0.568ssys 0m0.080s
Of course, on the second run the real time reduces (for me it's about0.5), as HDD already "knows" what I want, but since it is for loginshell, it will always be 2-3 seconds because of HDD.

Toggle quote (8 lines)

>> But actually, even if it was several milliseconds, I still wouldn't>> like it, as (IMHO) /etc/profile should only set variables, and not run>> external programs.>> I don’t buy this “principle”: /etc/profile is a program, and the output> of --search-paths is trusted to contain only environment variable> setting.

Sure, it's just my opinion (OK, let call it "faith"): I consider runningexternal programs in "/etc/profile" malicious.

Toggle quote (3 lines)

> In the discussion of this bug, we tried hard to avoid resorting to> invoking a program, but ultimately no other solution came out.

I don't need a solution for this bug, I just want to have an option toavoid invoking "guix package --search-paths" in my "/etc/profile".

Toggle quote (21 lines)>>>> I would really like to have an option to avoid this.  Is it possible?>>>>>> Not that I know of.  Please read <http://bugs.gnu.org/20255>.>>>> What about making some environment variable which will be honored by>> 'operating-system-etc-service' procedure.  So depending on this variable>> that 'eval ...' command will or will not be added to "/etc/profile">> during 'guix system ...' process.>>>> For example, when I do:>>>>   GUIX_IGNORE_SYSTEM_PROFILE_ENV=1 guix system build my-config.scm>>>> the "etc/profile" of the built system will not contain those 'eval ...'>> lines.  WDYT?>> This would be unreasonable.  We’re talking about a basic feature here.> If basic features are broken to the point that we prefer to offer ways> to bypass them, and have a semi-broken system, then there’s a problem,> IMO.

Sorry, but I would really like to bypass this feature, as I don't likeit.  For me, what you suggest sounds: «We'll not give a freedom to auser to disable this feature, because we know better what is good forhim/her».  All I ask is to give me such a freedom.
Using --search-paths with several profiles is a great feature (thank youfor it!) and I like it, but consider the following use-case: for somereason I like to manage several profiles instead of a single"~/.guix-profile", so I can put:
eval `guix package -p /run/current-system/profile \                   -p ~/.guix-profile \                   -p ~/my-guix-profiles/foo \                   -p ~/my-guix-profiles/bar \                   --search-paths`
in my "~/.bash_profile".  So I don't like to have the same command butonly for 2 profiles in my "/etc/profile".  Please, give me an option todisable this feature.
-- Alex

Ludovic Courtès wrote on 22 Nov 2015 11:52

Recipients:(name . Alex Kost)(address . alezost@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87lh9q1f2i.fsf@gnu.org

Alex Kost <alezost@gmail.com> skribis:

Toggle quote (12 lines)>>> At first, because of the slowdown: it may be a few hundred milliseconds>>> for you, but it's several seconds for me.>>>> Really?  Can you show the output of:>>>>   time guix package -p /run/current-system/profile \>>                     -p ~/.guix-profile --search-paths>> real	0m2.634s> user	0m0.568s> sys	0m0.080s

Ouch, that’s a problem. This suggests that this is 2 seconds of I/O.I’m not sure what can be done to improve that.

Toggle quote (6 lines)

>> In the discussion of this bug, we tried hard to avoid resorting to>> invoking a program, but ultimately no other solution came out.>> I don't need a solution for this bug, I just want to have an option to> avoid invoking "guix package --search-paths" in my "/etc/profile".

Are you denying that this is a bug? Are you denying that there’s ausability issue at hand?
To me, what 宋文武 reported at the beginning of this thread is ausability issue. We’ve hacked around it so far, but we know there arecases where the hacks aren’t enough.
We could declare it as “won’t fix”, but I’m not comfortable with that.

Toggle quote (14 lines)>>> For example, when I do:>>>>>>   GUIX_IGNORE_SYSTEM_PROFILE_ENV=1 guix system build my-config.scm>>>>>> the "etc/profile" of the built system will not contain those 'eval ...'>>> lines.  WDYT?>>>> This would be unreasonable.  We’re talking about a basic feature here.>> If basic features are broken to the point that we prefer to offer ways>> to bypass them, and have a semi-broken system, then there’s a problem,>> IMO.>> Sorry, but I would really like to bypass this feature

[...]
I very well understand your concern, so thanks for chiming in.Please let’s also consider the bug at hand.
The solution I came up with might be inadequate. Then we need to comeup with an alternate proposal, or to resign and mark it as “wontfix.”
What would you suggest?
Thanks,Ludo’.

Alex Kost wrote on 22 Nov 2015 19:44

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20255@debbugs.gnu.org)

Message-ID:877fl9q3gv.fsf@gmail.com

Ludovic Courtès (2015-11-22 13:52 +0300) wrote:

Toggle quote (26 lines)> Alex Kost <alezost@gmail.com> skribis:>>>>> At first, because of the slowdown: it may be a few hundred milliseconds>>>> for you, but it's several seconds for me.>>>>>> Really?  Can you show the output of:>>>>>>   time guix package -p /run/current-system/profile \>>>                     -p ~/.guix-profile --search-paths>>>> real	0m2.634s>> user	0m0.568s>> sys	0m0.080s>> Ouch, that’s a problem.  This suggests that this is 2 seconds of I/O.> I’m not sure what can be done to improve that.>>>> In the discussion of this bug, we tried hard to avoid resorting to>>> invoking a program, but ultimately no other solution came out.>>>> I don't need a solution for this bug, I just want to have an option to>> avoid invoking "guix package --search-paths" in my "/etc/profile".>> Are you denying that this is a bug?  Are you denying that there’s a> usability issue at hand?

I agree it's a usability issue.

Toggle quote (6 lines)

> To me, what 宋文武 reported at the beginning of this thread is a> usability issue. We’ve hacked around it so far, but we know there are> cases where the hacks aren’t enough.>> We could declare it as “won’t fix”, but I’m not comfortable with that.

No, no, I'm against “won't fix”. I don't mind if it's called a bug, anda solution you suggest is the best, but it suits only the default caseof a single user profile. If I have several user profiles, it doesnothing useful for me, only wastes the time.

Toggle quote (19 lines)>>>> For example, when I do:>>>>>>>>   GUIX_IGNORE_SYSTEM_PROFILE_ENV=1 guix system build my-config.scm>>>>>>>> the "etc/profile" of the built system will not contain those 'eval ...'>>>> lines.  WDYT?>>>>>> This would be unreasonable.  We’re talking about a basic feature here.>>> If basic features are broken to the point that we prefer to offer ways>>> to bypass them, and have a semi-broken system, then there’s a problem,>>> IMO.>>>> Sorry, but I would really like to bypass this feature>> [...]>> I very well understand your concern, so thanks for chiming in.> Please let’s also consider the bug at hand.

OK, for the bug at hand, invoking "guix package --search-paths" lookslike the only possible solution, but please don't commit this patchwithout giving a user a chance to decide what to put in /etc/profile.

Toggle quote (3 lines)

> The solution I came up with might be inadequate. Then we need to come> up with an alternate proposal, or to resign and mark it as “wontfix.”

It is adequate and I'm not against it.

Toggle quote (2 lines)

> What would you suggest?

After all, I realized what is my main concern: "/etc/profile" isnon-editable.  If I don't like some pieces of this file, I can donothing, and I just have to live with it and suffer.  Ideally I wouldlike to decide what pieces I want to put in /etc/profile and what Idon't.  But it's probably not possible, so…
… what I suggest now is just to give an option to avoid generating thedefault /etc/profile.  What about making an 'operating-system' field forthis file (similar to 'sudoers-file' or 'hosts-file')?  So when such'profile-file' is specified, it will be used instead of the default one(of course, it should be mentioned in the manual that it's only forthose users who are sure what they do).
If this 'profile-file' field appears, I will gladly use it, and I willnot object to any future changes in /etc/profile.
-- Alex

Ludovic Courtès wrote on 23 Nov 2015 00:04

Recipients:(name . Alex Kost)(address . alezost@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87h9kdy6ty.fsf@gnu.org

Alex Kost <alezost@gmail.com> skribis:

Toggle quote (2 lines)

> Ludovic Courtès (2015-11-22 13:52 +0300) wrote:

[...]

Toggle quote (9 lines)

>> To me, what 宋文武 reported at the beginning of this thread is a>> usability issue. We’ve hacked around it so far, but we know there are>> cases where the hacks aren’t enough.>>>> We could declare it as “won’t fix”, but I’m not comfortable with that.>> No, no, I'm against “won't fix”. I don't mind if it's called a bug, and> a solution you suggest is the best,

OK.

Toggle quote (4 lines)

> but it suits only the default case of a single user profile. If I> have several user profiles, it does nothing useful for me, only wastes> the time.

I think this is fine. ~/.guix-profile is treated specially in manyways. I think users do not expect other profiles to be magically takeninto account.

Toggle quote (4 lines)

> OK, for the bug at hand, invoking "guix package --search-paths" looks> like the only possible solution, but please don't commit this patch> without giving a user a chance to decide what to put in /etc/profile.

OK.

Toggle quote (5 lines)

>> The solution I came up with might be inadequate. Then we need to come>> up with an alternate proposal, or to resign and mark it as “wontfix.”>> It is adequate and I'm not against it.

OK. To me, that it takes 2 seconds on your machines suggests that it’snot great either.

Toggle quote (15 lines)>> What would you suggest?>> After all, I realized what is my main concern: "/etc/profile" is> non-editable.  If I don't like some pieces of this file, I can do> nothing, and I just have to live with it and suffer.  Ideally I would> like to decide what pieces I want to put in /etc/profile and what I> don't.  But it's probably not possible, so…>> … what I suggest now is just to give an option to avoid generating the> default /etc/profile.  What about making an 'operating-system' field for> this file (similar to 'sudoers-file' or 'hosts-file')?  So when such> 'profile-file' is specified, it will be used instead of the default one> (of course, it should be mentioned in the manual that it's only for> those users who are sure what they do).

I think we could make an /etc/profile-service that receives snippetsmeant to be glued together into the final /etc/profile. Users couldspecify the top or bottom of the file.
There could be a combined-search-paths-service that implements thesolution I proposed here.
WDYT?

Toggle quote (3 lines)

> If this 'profile-file' field appears, I will gladly use it, and I will> not object to any future changes in /etc/profile.

Of course we want to offer this flexibility.  But I think it’s alsoimportant to discuss the defaults, to make sure they are acceptable tomany and that they improve the “user experience.”
Thanks,Ludo’.

Alex Kost wrote on 23 Nov 2015 12:55

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20255@debbugs.gnu.org)

Message-ID:871tbh53rt.fsf@gmail.com

Ludovic Courtès (2015-11-23 02:04 +0300) wrote:

Toggle quote (14 lines)> Alex Kost <alezost@gmail.com> skribis:>>> Ludovic Courtès (2015-11-22 13:52 +0300) wrote:>> [...]>>> but it suits only the default case of a single user profile.  If I>> have several user profiles, it does nothing useful for me, only wastes>> the time.>> I think this is fine.  ~/.guix-profile is treated specially in many> ways.  I think users do not expect other profiles to be magically taken> into account.

Yes, this is a good default option, all I wanted to say is if I don'tuse Guix in a default way, I would like to change this default option tosuit my needs.

Toggle quote (24 lines)>>> What would you suggest?>>>> After all, I realized what is my main concern: "/etc/profile" is>> non-editable.  If I don't like some pieces of this file, I can do>> nothing, and I just have to live with it and suffer.  Ideally I would>> like to decide what pieces I want to put in /etc/profile and what I>> don't.  But it's probably not possible, so…>>>> … what I suggest now is just to give an option to avoid generating the>> default /etc/profile.  What about making an 'operating-system' field for>> this file (similar to 'sudoers-file' or 'hosts-file')?  So when such>> 'profile-file' is specified, it will be used instead of the default one>> (of course, it should be mentioned in the manual that it's only for>> those users who are sure what they do).>> I think we could make an /etc/profile-service that receives snippets> meant to be glued together into the final /etc/profile.  Users could> specify the top or bottom of the file.>> There could be a combined-search-paths-service that implements the> solution I proposed here.>> WDYT?

I agree, the more ways to change a default behaviour, the better.Although I will not use these things if there will be ‘profile-file’field that allows to specify my own "/etc/profile".

Toggle quote (5 lines)

>> If this 'profile-file' field appears, I will gladly use it, and I will>> not object to any future changes in /etc/profile.>> Of course we want to offer this flexibility.

Great! So is it OK to send a patch for adding ‘profile-file’ field?

Toggle quote (4 lines)

> But I think it’s also> important to discuss the defaults, to make sure they are acceptable to> many and that they improve the “user experience.”

I'm probably not the person to discuss the defaults, as very often Ifind defaults inappropriate.  For example, invoking "guix package--search-paths" in /etc/profile is a totally unacceptable default forme (sorry for mentioning it all the time :-))
-- Alex

Ludovic Courtès wrote on 23 Nov 2015 15:31

Recipients:(name . Alex Kost)(address . alezost@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87vb8sss7j.fsf@gnu.org

Alex Kost <alezost@gmail.com> skribis:

Toggle quote (20 lines)> Ludovic Courtès (2015-11-23 02:04 +0300) wrote:>>> Alex Kost <alezost@gmail.com> skribis:>>>>> Ludovic Courtès (2015-11-22 13:52 +0300) wrote:>>>> [...]>>>>> but it suits only the default case of a single user profile.  If I>>> have several user profiles, it does nothing useful for me, only wastes>>> the time.>>>> I think this is fine.  ~/.guix-profile is treated specially in many>> ways.  I think users do not expect other profiles to be magically taken>> into account.>> Yes, this is a good default option, all I wanted to say is if I don't> use Guix in a default way, I would like to change this default option to> suit my needs.

IMO this is beyond the scope of this discussion: /etc/profile alreadysources ~/.guix-profile/etc/profile explicitly, and not anything else.
[...]

Toggle quote (20 lines)>>> … what I suggest now is just to give an option to avoid generating the>>> default /etc/profile.  What about making an 'operating-system' field for>>> this file (similar to 'sudoers-file' or 'hosts-file')?  So when such>>> 'profile-file' is specified, it will be used instead of the default one>>> (of course, it should be mentioned in the manual that it's only for>>> those users who are sure what they do).>>>> I think we could make an /etc/profile-service that receives snippets>> meant to be glued together into the final /etc/profile.  Users could>> specify the top or bottom of the file.>>>> There could be a combined-search-paths-service that implements the>> solution I proposed here.>>>> WDYT?>> I agree, the more ways to change a default behaviour, the better.> Although I will not use these things if there will be ‘profile-file’> field that allows to specify my own "/etc/profile".

[...]

Toggle quote (2 lines)

> Great! So is it OK to send a patch for adding ‘profile-file’ field?

Hmm, I’m not sure if we want to give direct access to /etc/profile likethis.
The problem is that several things in there are here to make the systemwork, and to to make it conform to the ‘operating-system’ declaration,such as:

Toggle snippet (8 lines)

export LANG="en_US.utf8"export TZ="Europe/Paris"export TZDIR="/gnu/store/rwvf6xqgsyb8bmpi7rwk9fildnwvzrv5-tzdata-2015c/share/zoneinfo"
# Tell 'modprobe' & co. where to look for modules.export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules

The risk I see with adding a raw ‘profile-file’ option is that newcomersmay end up getting rid of such things without really noticing, and thengetting a broken system.
What about instead giving a way to populate the top and/or bottom ofthis file? Controversial parts, if any, could still be turned on andoff by adding or removing services that add these lines?
I think we should open a separate bug report to discuss this.

Toggle quote (7 lines)

>> But I think it’s also>> important to discuss the defaults, to make sure they are acceptable to>> many and that they improve the “user experience.”>> I'm probably not the person to discuss the defaults, as very often I> find defaults inappropriate.

Understood.  I’m sure you’ll understand, though, that it’s in theinterest of the project and its users to provide a good user experiencefirsthand.
Thanks for your feedback,Ludo’.

Ludovic Courtès wrote on 24 Nov 2015 18:22

Recipients:(name . Alex Kost)(address . alezost@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:877fl7cnxl.fsf@gnu.org

Alex Kost <alezost@gmail.com> skribis:

Toggle quote (2 lines)

> Ludovic Courtès (2015-11-21 23:10 +0300) wrote:

[...]

Toggle quote (9 lines)

>> Really? Can you show the output of:>>>> time guix package -p /run/current-system/profile \>> -p ~/.guix-profile --search-paths>> real 0m2.634s> user 0m0.568s> sys 0m0.080s

Could you measure again after cc3de1d?
As it turns out, ‘guix package’ loads way too much and also stats toomuch, at least for simple operations like --search-paths.
Thanks,Ludo’.

Alex Kost wrote on 30 Nov 2015 10:08

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20255@debbugs.gnu.org)

Message-ID:874mg3dfbo.fsf@gmail.com

Ludovic Courtès (2015-11-24 20:22 +0300) wrote:

Toggle quote (20 lines)> Alex Kost <alezost@gmail.com> skribis:>>> Ludovic Courtès (2015-11-21 23:10 +0300) wrote:>> [...]>>>> Really?  Can you show the output of:>>>>>>   time guix package -p /run/current-system/profile \>>>                     -p ~/.guix-profile --search-paths>>>> real	0m2.634s>> user	0m0.568s>> sys	0m0.080s>> Could you measure again after cc3de1d?>> As it turns out, ‘guix package’ loads way too much and also stats too> much, at least for simple operations like --search-paths.

real 0m1.122suser 0m0.244ssys 0m0.044s
I measured it several times with a "cold" HDD (I mean when appropriatefiles were not cached), and the real time was always 1.0—1.3s. Bigimprovement! Thank you very much for this, autoloads are great!
-- Alex

Ludovic Courtès wrote on 30 Nov 2015 13:25

Recipients:(name . Alex Kost)(address . alezost@gmail.com)(address . 20255@debbugs.gnu.org)

Message-ID:87r3j7d68z.fsf@gnu.org

Alex Kost <alezost@gmail.com> skribis:

Toggle quote (30 lines)> Ludovic Courtès (2015-11-24 20:22 +0300) wrote:>>> Alex Kost <alezost@gmail.com> skribis:>>>>> Ludovic Courtès (2015-11-21 23:10 +0300) wrote:>>>> [...]>>>>>> Really?  Can you show the output of:>>>>>>>>   time guix package -p /run/current-system/profile \>>>>                     -p ~/.guix-profile --search-paths>>>>>> real	0m2.634s>>> user	0m0.568s>>> sys	0m0.080s>>>> Could you measure again after cc3de1d?>>>> As it turns out, ‘guix package’ loads way too much and also stats too>> much, at least for simple operations like --search-paths.>> real	0m1.122s> user	0m0.244s> sys	0m0.044s>> I measured it several times with a "cold" HDD (I mean when appropriate> files were not cached), and the real time was always 1.0—1.3s.  Big> improvement!  Thank you very much for this, autoloads are great!

Great, thanks for testing! That’s still too much to my state, but it’salready an improvement.
Ludo’.

Ludovic Courtès wrote on 19 Dec 2015 18:23

control message for bug #20255

Recipients:(address . control@debbugs.gnu.org)

Message-ID:8737uyz71l.fsf@gnu.org

tags 20255 patch

zimoun wrote on 21 Feb 2020 16:53

(old)bug#20255: 'search-paths' should respect both user and system profiles

Recipients:(address . 20255@debbugs.gnu.org)

Message-ID:CAJ3okZ3pg6q=Z29tfuDtdCwRrC6FYbFma_qAtAb2mVw4CTMW3A@mail.gmail.com

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 profileThen "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 thepatch:

Toggle snippet (6 lines)

+ 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 viaan environment variable. I am not sure to follow where the discussionhad been going then.

Well, is the issue still happening 4 years later?If yes, what should be the fix? What is the status quo?If no, let close the bug.

Note that other patches are still pending [4] and [5] -- probablyirrelevant now.

All the best,simon

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#41[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#44[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#8[5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#26

Alex Kost wrote on 21 Feb 2020 18:18

Recipients:(name . zimoun)(address . zimon.toutoune@gmail.com)

Message-ID:87eeun97ur.fsf@gmail.com

zimoun (2020-02-21 16:53 +0100) wrote:

Toggle quote (26 lines)> 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 tochange 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 thatpatch so it was never committed.
-- Alex

zimoun wrote on 18 Dec 2020 21:27

bug#20255: «the Oldest» [PATCH] 'search-paths' should respect both user and system profiles

Recipients:

Message-ID:86v9cyuaev.fsf_-_@gmail.com

Hi,
The bug#20255 [#] is the oldest patch, still there even if almost isdone. Let enjoy this patch squash day on Dec. the 18th [0] to closeit. ;-)
Below the summary I wrote couple of months ago. And the Alex’s answer:
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.
Let’s tackle it! :-)
0: https://lists.gnu.org/archive/html/guix-devel/2020-12/msg00215.html

All the best,simon
#: http://issues.guix.gnu.org/issue/20255

On Fri, 21 Feb 2020 at 16:53, zimoun <zimon.toutoune@gmail.com> wrote:

Toggle quote (39 lines)> 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.>> Well, is the issue still happening 4 years later?> If yes, what should be the fix? What is the status quo?> If no, let close the bug.>> Note that other patches are still pending [4] and [5] -- probably> irrelevant now.>> All the best,> simon>>> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255> [2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#41> [3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#44> [4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#8> [5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#26

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date