Export environment variables only in `guix environment`.

Export environment variables only in `guix environment`.

[Fis Trivial]

* Problem
The exported environment variables can cause various problems in foreign
distribution(1)(2). And besides, The long list of environment variables(4)
injected into user's login shell makes the user's environment impure.
So, I believe that if I want to run guix safely on a foreign distributions, I
need to eliminate the need for exporting environment variables from guix to my
login shell.

* From nix
I tried nix and found that they actually don't export any library related
environment variable by default, the only non-prefixed env in their profile file
is $PATH, so the above mentioned problem cannot arise on the nix side. But the
simple solution isn't perfect either.  In short, one cannot access any library
installed by nix without launching `nix-shell`(much like `guix environment`).
Even worse, you need to specify all the needed libraries before launching it,
which is extremely inconvenient, especially when you use interpreters like
python shell. That's not good for Unix, where casual programming is a daily
practice.
Around the problem, they also have some discussions, for details, please refer
to(1).

So, I am thinking if we can come to a middle land, that we *ONLY* source those
exported environment variables when launching `guix environment` or
`guix container`, and let the behavior controllable by command arguments. For
example:
`guix environment --export-all-envs`
 or
`guix environment --export GI_TYPELIB_PATH`


[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30093
[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30229
[3]: https://github.com/NixOS/nixpkgs/issues/10597

[4]: The envs exported by guix on my system, copied from ~/.guix-profile/etc/profile

export PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/bin:${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/sbin${PATH:+:}$PATH"
export C_INCLUDE_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/include${C_INCLUDE_PATH:+:}$C_INCLUDE_PATH"
export CPLUS_INCLUDE_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/include${CPLUS_INCLUDE_PATH:+:}$CPLUS_INCLUDE_PATH"
export LIBRARY_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/lib:${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/lib64${LIBRARY_PATH:+:}$LIBRARY_PATH"
export XDG_DATA_DIRS="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
export GIO_EXTRA_MODULES="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES"
export GI_TYPELIB_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/lib/girepository-1.0${GI_TYPELIB_PATH:+:}$GI_TYPELIB_PATH"
export PYTHONPATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/lib/python3.5/site-packages${PYTHONPATH:+:}$PYTHONPATH"
export GUIX_GTK3_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/lib/gtk-3.0${GUIX_GTK3_PATH:+:}$GUIX_GTK3_PATH"
export PERL5LIB="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/lib/perl5/site_perl${PERL5LIB:+:}$PERL5LIB"
export GUILE_LOAD_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/share/guile/site/2.2${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
export GUILE_LOAD_COMPILED_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/share/guile/site/2.2${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"
export CMAKE_PREFIX_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/${CMAKE_PREFIX_PATH:+:}$CMAKE_PREFIX_PATH"
export PKG_CONFIG_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/lib/pkgconfig:${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/share/pkgconfig${PKG_CONFIG_PATH:+:}$PKG_CONFIG_PATH"
export CPATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/include${CPATH:+:}$CPATH"
export SSL_CERT_DIR="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/etc/ssl/certs${SSL_CERT_DIR:+:}$SSL_CERT_DIR"
export GHC_PACKAGE_PATH="${GUIX_PROFILE:-/gnu/store/5myb7fcfvlmcxb2yw1kra70603ma56fm-profile}/lib/ghc-8.0.2/package.conf.d${GHC_PACKAGE_PATH:+:}$GHC_PACKAGE_PATH"

Re: Export environment variables only in `guix environment`.

[Ludovic Courtès]

Hello,

Fis Trivial <ybbs.daans@hotmail.com> skribis:

> * Problem
> The exported environment variables can cause various problems in foreign
> distribution(1)(2). And besides, The long list of environment variables(4)
> injected into user's login shell makes the user's environment impure.
> So, I believe that if I want to run guix safely on a foreign distributions, I
> need to eliminate the need for exporting environment variables from guix to my
> login shell.

Can you clarify what problems you are facing?

I remember one problematic case on foreign distros, that of XDG_DATA_DIRS:

  https://bugs.gnu.org/26202

The environment variable settings that ‘guix package’ produces are here
to ensure that software installed with Guix will work as expected.
Ignoring them wholesale (à la Nix) doesn’t sound like a good idea.  :-)

Thanks,
Ludo’.

Re: Export environment variables only in `guix environment`.

[Pjotr Prins]

On Thu, Feb 01, 2018 at 12:40:39AM +0100, Ludovic Courtès wrote:
> Hello,
> 
> Fis Trivial <ybbs.daans@hotmail.com> skribis:
> 
> > * Problem
> > The exported environment variables can cause various problems in foreign
> > distribution(1)(2). And besides, The long list of environment variables(4)
> > injected into user's login shell makes the user's environment impure.
> > So, I believe that if I want to run guix safely on a foreign distributions, I
> > need to eliminate the need for exporting environment variables from guix to my
> > login shell.

Not a problem, just don't do it :). To import the invironments 
run

  . $PROFILE/etc/profile

I do that in scripts or when I need something. Even so, many programs
work with just the PATH set.

Pj.

Re: Export environment variables only in `guix environment`.

[Fis Trivial]

Hi:

Ludovic Courtès writes:

> Hello,
>
> Fis Trivial <ybbs.daans@hotmail.com> skribis:
>
>> * Problem
>> The exported environment variables can cause various problems in foreign
>> distribution(1)(2). And besides, The long list of environment variables(4)
>> injected into user's login shell makes the user's environment impure.
>> So, I believe that if I want to run guix safely on a foreign distributions, I
>> need to eliminate the need for exporting environment variables from guix to my
>> login shell.
>
> Can you clarify what problems you are facing?
>

There are 2 footnote notations after "foreign distributions", (1) and
(2), the footnotes are appended at the end of origin mail. Those are 2
bug reports from me:). (3) from the origin mail is a github issue about
this problem from NixOS.

> I remember one problematic case on foreign distros, that of XDG_DATA_DIRS:
>
>   https://bugs.gnu.org/26202
>

I read this bug report before, this particular env is about gnome shell
accessing installed GUI applications, not directly related to accessing
libraries. It's hard to avoid if you want to use GUI apps from guix. But
libraries related envs like PYTHONPATH can be avoided.

> The environment variable settings that ‘guix package’ produces are here
> to ensure that software installed with Guix will work as expected.
> Ignoring them wholesale (à la Nix) doesn’t sound like a good idea.  :-)
>
> Thanks,
> Ludo’.

Thanks for your time.

Re: Export environment variables only in `guix environment`.

[Fis Trivial]

Pjotr Prins writes:

> On Thu, Feb 01, 2018 at 12:40:39AM +0100, Ludovic Courtès wrote:
>> Hello,
>> 
>> Fis Trivial <ybbs.daans@hotmail.com> skribis:
>> 
>> > * Problem
>> > The exported environment variables can cause various problems in foreign
>> > distribution(1)(2). And besides, The long list of environment variables(4)
>> > injected into user's login shell makes the user's environment impure.
>> > So, I believe that if I want to run guix safely on a foreign distributions, I
>> > need to eliminate the need for exporting environment variables from guix to my
>> > login shell.
>
> Not a problem, just don't do it :). To import the invironments 
> run
>
>   . $PROFILE/etc/profile
>
> I do that in scripts or when I need something. Even so, many programs
> work with just the PATH set.
>
> Pj.

Currently my solution is separating the profile file into two parts, one
contains PATH and SSL related envs, the second part contains all the
others exported by guix. Then I source the first part in login shell
while the second part in interactive shell.

It's a little hack, which means not the way it should work, to me that's
a problem. Guix is still young, we don't have many legacy problems that
needs hacks to solve. I love guix project, which is elegant from the
choice of scripting language and the underlying functional logic. I hope
that if we be picky enough, Guix can stay this way. So lets eliminate
these hacks. :)

Thanks for your time.

Re: Export environment variables only in `guix environment`.

[Chris Marusich]

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

Fis Trivial <ybbs.daans@hotmail.com> writes:

> * Problem
> The exported environment variables can cause various problems in foreign
> distribution(1)(2). And besides, The long list of environment variables(4)
> injected into user's login shell makes the user's environment impure.

A lot of software is intended to be dynamically composed with other
software at run-time through the use of mechanisms like environment
variables.  Other mechanisms of dynamic composition at run-time also
exist, such as configuration files (e.g., ~/.emacs).  Consider the
EDITOR environment variable, which is traditionally used to indicate the
user's default text editor.  We COULD try to control the EDITOR
environment variable with Guix, but then you would have to update your
Guix profile every time you wanted to change your default text editor.
It would be "more pure," but less convenient.

To a certain extent, I think it is desirable (and unavoidable?) to use
these mechanisms to dynamically configure and compose software.
However, sometimes you can still let Guix control the environment
variables without making it inconvenient, and without letting the
environment variables set by Guix "leak" into the user's environment.
For example, you can wrap programs in a script that sets their
environment variables explicitly, rather than relying on the environment
variables being set correctly by the user.  Guix does this already for a
variety of packages (see the "asunder" package for a simple example).

For more information, check out section 7.1.1 "Principles" of the the
Nix thesis [1].  The entire section surrounding that phrase is also relevant
and interesting.

Footnotes: 
[1]  https://nixos.org/~eelco/pubs/phd-thesis.pdf

-- 
Chris

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

Re: Export environment variables only in `guix environment`.

[Pjotr Prins]

On Thu, Feb 01, 2018 at 06:26:57PM +0100, Chris Marusich wrote:
> Fis Trivial <ybbs.daans@hotmail.com> writes:
> 
> > * Problem
> > The exported environment variables can cause various problems in foreign
> > distribution(1)(2). And besides, The long list of environment variables(4)
> > injected into user's login shell makes the user's environment impure.
> 
> A lot of software is intended to be dynamically composed with other
> software at run-time through the use of mechanisms like environment
> variables.  Other mechanisms of dynamic composition at run-time also
> exist, such as configuration files (e.g., ~/.emacs).  Consider the
> EDITOR environment variable, which is traditionally used to indicate the
> user's default text editor.  We COULD try to control the EDITOR
> environment variable with Guix, but then you would have to update your
> Guix profile every time you wanted to change your default text editor.
> It would be "more pure," but less convenient.

Exactly, we need to match what existing software expects. There is no
real way around that. Guix use of environment variables is 'limited'.
Take the list for a compilation with D, C, R, git and Python in the
profile you get:

./pre-inst-env guix package --search-paths -p ~/opt/ldc

generic:

  export PATH="/home/wrk/opt/ldc/bin:/home/wrk/opt/ldc/sbin"
  export XDG_DATA_DIRS="/home/wrk/opt/ldc/share"

Special:

  export CPATH="/home/wrk/opt/ldc/include"
  export LIBRARY_PATH="/home/wrk/opt/ldc/lib"
  export C_INCLUDE_PATH="/home/wrk/opt/ldc/include"
  export CPLUS_INCLUDE_PATH="/home/wrk/opt/ldc/include"
  export PYTHONPATH="/home/wrk/opt/ldc/lib/python2.7/site-packages"
  export GIT_EXEC_PATH="/home/wrk/opt/ldc/libexec/git-core"
  export R_LIBS_SITE="/home/wrk/opt/ldc/site-library/"
  export GUIX_GTK3_PATH="/home/wrk/opt/ldc/lib/gtk-3.0"
  export GI_TYPELIB_PATH="/home/wrk/opt/ldc/lib/girepository-1.0"
  export GIO_EXTRA_MODULES="/home/wrk/opt/ldc/lib/gio/modules"

All pretty clear and hardly a disaster. I don't set any of these by
default on login.

Main thing is to manage environment variables to match the
software. When you create a profile with only one package in it, the
use of environment settings will be limited to what the software
expects. 

There is no bleeding of variables into the environment unless you make
it to.

Pj.