[PATCH 0/1] Add '--inherit' to 'guix environment'

  • Done
  • quality assurance status badge
Details
5 participants
  • Thompson, David
  • Eric Bavier
  • Kyle Meyer
  • Ludovic Courtès
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 15 Feb 2019 11:42
(address . guix-patches@gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
20190215104257.16275-1-ludo@gnu.org
Hello,

This new option allows to specify additional variables to be inherited
in a “pure” (semi-pure?) environment.

The main motivation was the use of the SLURM batch scheduler, which
defines environment variables that you need to preserve so that things
like ‘mpirun’ work correctly.

Thoughts?

Ludo’.

Ludovic Courtès (1):
environment: Add '--inherit'.

doc/guix.texi | 21 ++++++++++++--
guix/scripts/environment.scm | 53 +++++++++++++++++++++++++-----------
tests/guix-environment.sh | 15 +++++++++-
3 files changed, 69 insertions(+), 20 deletions(-)

--
2.20.1
L
L
Ludovic Courtès wrote on 15 Feb 2019 11:49
[PATCH 1/1] environment: Add '--inherit'.
(address . 34486@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)
20190215104928.16509-1-ludo@gnu.org
From: Ludovic Courtès <ludovic.courtes@inria.fr>

* guix/scripts/environment.scm (purify-environment): Add 'white-list'
parameter and honor it.
(create-environment): Add #:white-list parameter and honor it.
(launch-environment): Likewise.
(launch-environment/fork): Likewise.
(show-help, %options): Add '--inherit'.
(guix-environment): Define 'white-list' and pass it to
'launch-environment/fork'.
* tests/guix-environment.sh: Test '--inherit'.
* doc/guix.texi (Invoking guix environment): Document it.
---
doc/guix.texi | 21 ++++++++++++--
guix/scripts/environment.scm | 53 +++++++++++++++++++++++++-----------
tests/guix-environment.sh | 15 +++++++++-
3 files changed, 69 insertions(+), 20 deletions(-)

Toggle diff (180 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index 1ac077d98a..68d39ed02f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4454,9 +4454,24 @@ default behavior. Packages appearing after are interpreted as packages
that will be added to the environment directly.
@item --pure
-Unset existing environment variables when building the new environment.
-This has the effect of creating an environment in which search paths
-only contain package inputs.
+Unset existing environment variables when building the new environment, except
+those specified with @option{--inherit} (see below.) This has the effect of
+creating an environment in which search paths only contain package inputs.
+
+@item --inherit=@var{regexp}
+When used alongside @option{--pure}, inherit all the environment variables
+matching @var{regexp}---in other words, put them on a ``white list'' of
+environment variables that must be preserved.
+
+@example
+guix environment --pure --inherit=^SLURM --ad-hoc openmpi @dots{} \
+ -- mpirun @dots{}
+@end example
+
+This example runs @command{mpirun} in a context where the only environment
+variables defined are @code{PATH}, environment variables whose name starts
+with @code{SLURM}, as well as the usual ``precious'' variables (@code{HOME},
+@code{USER}, etc.)
@item --search-paths
Display the environment variable definitions that make up the
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 3143ea9281..3966531efa 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -57,20 +57,27 @@
(define %default-shell
(or (getenv "SHELL") "/bin/sh"))
-(define (purify-environment)
- "Unset almost all environment variables. A small number of variables such
-as 'HOME' and 'USER' are left untouched."
+(define (purify-environment white-list)
+ "Unset all environment variables except those that match the regexps in
+WHITE-LIST and those listed in %PRECIOUS-VARIABLES. A small number of
+variables such as 'HOME' and 'USER' are left untouched."
(for-each unsetenv
- (remove (cut member <> %precious-variables)
+ (remove (lambda (variable)
+ (or (member variable %precious-variables)
+ (find (cut regexp-exec <> variable)
+ white-list)))
(match (get-environment-variables)
(((names . _) ...)
names)))))
-(define* (create-environment profile manifest #:key pure?)
- "Set the environment variables specified by MANIFEST for PROFILE. When PURE?
-is #t, unset the variables in the current environment. Otherwise, augment
-existing environment variables with additional search paths."
- (when pure? (purify-environment))
+(define* (create-environment profile manifest
+ #:key pure? (white-list '()))
+ "Set the environment variables specified by MANIFEST for PROFILE. When
+PURE? is #t, unset the variables in the current environment except those that
+match the regexps in WHITE-LIST. Otherwise, augment existing environment
+variables with additional search paths."
+ (when pure?
+ (purify-environment white-list))
(for-each (match-lambda
((($ <search-path-specification> variable _ separator) . value)
(let ((current (getenv variable)))
@@ -133,6 +140,8 @@ COMMAND or an interactive shell in that environment.\n"))
of only their inputs"))
(display (G_ "
--pure unset existing environment variables"))
+ (display (G_ "
+ --inherit=REGEXP inherit environment variables that match REGEXP"))
(display (G_ "
--search-paths display needed environment variable definitions"))
(display (G_ "
@@ -206,6 +215,11 @@ COMMAND or an interactive shell in that environment.\n"))
(option '("pure") #f #f
(lambda (opt name arg result)
(alist-cons 'pure #t result)))
+ (option '("inherit") #t #f
+ (lambda (opt name arg result)
+ (alist-cons 'inherit-regexp
+ (make-regexp* arg)
+ result)))
(option '(#\E "exec") #t #f ; deprecated
(lambda (opt name arg result)
(alist-cons 'exec (list %default-shell "-c" arg) result)))
@@ -397,25 +411,30 @@ and suitable for 'exit'."
(define primitive-exit/status (compose primitive-exit status->exit-code))
(define* (launch-environment command profile manifest
- #:key pure?)
+ #:key pure? (white-list '()))
"Run COMMAND in a new environment containing INPUTS, using the native search
paths defined by the list PATHS. When PURE?, pre-existing environment
-variables are cleared before setting the new ones."
+variables are cleared before setting the new ones, except those matching the
+regexps in WHITE-LIST."
;; Properly handle SIGINT, so pressing C-c in an interactive terminal
;; application works.
(sigaction SIGINT SIG_DFL)
- (create-environment profile manifest #:pure? pure?)
+ (create-environment profile manifest
+ #:pure? pure? #:white-list white-list)
(match command
((program . args)
(apply execlp program program args))))
-(define* (launch-environment/fork command profile manifest #:key pure?)
+(define* (launch-environment/fork command profile manifest
+ #:key pure? (white-list '()))
"Run COMMAND in a new process with an environment containing PROFILE, with
the search paths specified by MANIFEST. When PURE?, pre-existing environment
-variables are cleared before setting the new ones."
+variables are cleared before setting the new ones, except those matching the
+regexps in WHITE-LIST."
(match (primitive-fork)
(0 (launch-environment command profile manifest
- #:pure? pure?))
+ #:pure? pure?
+ #:white-list white-list))
(pid (match (waitpid pid)
((_ . status) status)))))
@@ -672,7 +691,8 @@ message if any test fails."
;; within the container.
'("/bin/sh")
(list %default-shell))))
- (mappings (pick-all opts 'file-system-mapping)))
+ (mappings (pick-all opts 'file-system-mapping))
+ (white-list (pick-all opts 'inherit-regexp)))
(when container? (assert-container-features))
@@ -741,4 +761,5 @@ message if any test fails."
(return
(exit/status
(launch-environment/fork command profile manifest
+ #:white-list white-list
#:pure? pure?))))))))))))))
diff --git a/tests/guix-environment.sh b/tests/guix-environment.sh
index 30b21028aa..ccbe027c7b 100644
--- a/tests/guix-environment.sh
+++ b/tests/guix-environment.sh
@@ -1,5 +1,5 @@
# GNU Guix --- Functional package management for GNU
-# Copyright © 2015, 2016, 2017, 2018 Ludovic Courtès <ludo@gnu.org>
+# Copyright © 2015, 2016, 2017, 2018, 2019 Ludovic Courtès <ludo@gnu.org>
#
# This file is part of GNU Guix.
#
@@ -49,6 +49,19 @@ test -x `sed -r 's/^export PATH="(.*)"/\1/' "$tmpdir/a"`/guile
cmp "$tmpdir/a" "$tmpdir/b"
+# Check '--inherit'.
+GUIX_TEST_ABC=1
+GUIX_TEST_DEF=2
+GUIX_TEST_XYZ=3
+export GUIX_TEST_ABC GUIX_TEST_DEF GUIX_TEST_XYZ
+guix environment --bootstrap --ad-hoc guile-bootstrap --pure \
+ --inherit='^GUIX_TEST_A' --inherit='^GUIX_TEST_D' \
+ -- "$SHELL" -c set > "$tmpdir/a"
+grep '^PATH=' "$tmpdir/a"
+grep '^GUIX_TEST_ABC=' "$tmpdir/a"
+grep '^GUIX_TEST_DEF=' "$tmpdir/a"
+if grep '^GUIX_TEST_XYZ=' "$tmpdir/a"; then false; else true; fi
+
# Make sure the exit value is preserved.
if guix environment --bootstrap --ad-hoc guile-bootstrap --pure \
-- guile -c '(exit 42)'
--
2.20.1
T
T
Thompson, David wrote on 15 Feb 2019 15:34
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ=Rwfa_90sHgjn8-pzboMZNYgyP86N60UvLNGPynWh-5JPzdw@mail.gmail.com
Hi Ludo,

On Fri, Feb 15, 2019 at 6:07 AM Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (14 lines)
>
> From: Ludovic Courtès <ludovic.courtes@inria.fr>
>
> * guix/scripts/environment.scm (purify-environment): Add 'white-list'
> parameter and honor it.
> (create-environment): Add #:white-list parameter and honor it.
> (launch-environment): Likewise.
> (launch-environment/fork): Likewise.
> (show-help, %options): Add '--inherit'.
> (guix-environment): Define 'white-list' and pass it to
> 'launch-environment/fork'.
> * tests/guix-environment.sh: Test '--inherit'.
> * doc/guix.texi (Invoking guix environment): Document it.

Seems like a good addition to me!

- Dave
R
R
Ricardo Wurmus wrote on 15 Feb 2019 15:54
Re: [bug#34486] [PATCH 0/1] Add '--inherit' to 'guix environment'
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 34486@debbugs.gnu.org)
87va1lrtjq.fsf@elephly.net
Hi,

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

Toggle quote (7 lines)
> This new option allows to specify additional variables to be inherited
> in a “pure” (semi-pure?) environment.
>
> The main motivation was the use of the SLURM batch scheduler, which
> defines environment variables that you need to preserve so that things
> like ‘mpirun’ work correctly.

Looks good to me. The same is needed for Grid Engine. Previously I
would use “env” with an installed profile for the same effect:

Toggle snippet (10 lines)
#!/bin/bash

profile=/path/to/.guix-profile
exec /bin/env - PATH=/opt/uge/bin/lx-amd64 \
SGE_CELL=default \
SGE_ARCH=lx-amd64 …
GUIX_LOCPATH=… \
/bin/bash --init-file "$profile/etc/profile"

I guess the only thing that’s missing now is to activate an installed
environment.

--
Ricardo
L
L
Ludovic Courtès wrote on 16 Feb 2019 01:05
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87imxkion6.fsf@gnu.org
Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (21 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> This new option allows to specify additional variables to be inherited
>> in a “pure” (semi-pure?) environment.
>>
>> The main motivation was the use of the SLURM batch scheduler, which
>> defines environment variables that you need to preserve so that things
>> like ‘mpirun’ work correctly.
>
> Looks good to me. The same is needed for Grid Engine. Previously I
> would use “env” with an installed profile for the same effect:
>
> #!/bin/bash
>
> profile=/path/to/.guix-profile
> exec /bin/env - PATH=/opt/uge/bin/lx-amd64 \
> SGE_CELL=default \
> SGE_ARCH=lx-amd64 …
> GUIX_LOCPATH=… \
> /bin/bash --init-file "$profile/etc/profile"

Oh so I guess this is an improvement. :-)

Pushed as e6e599fa0106f57b9de15f90dcab3795ff1575b6.

Toggle quote (3 lines)
> I guess the only thing that’s missing now is to activate an installed
> environment.

Something beyond --search-paths and etc/profile, right? I’m not sure
what it would look like.

Thanks for your feedback David & Ricardo!

Ludo’.
Closed
R
R
Ricardo Wurmus wrote on 16 Feb 2019 10:12
(name . Ludovic Courtès)(address . ludo@gnu.org)
87d0nsyu53.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (6 lines)
>> I guess the only thing that’s missing now is to activate an installed
>> environment.
>
> Something beyond --search-paths and etc/profile, right? I’m not sure
> what it would look like.

It doesn’t need to be much. People can “save” environments with
“--root” but they have no built-in mechanism to “load” an environment
that has been saved like that.

Loading can be done with “env /path/to/bash --init-file
$profile/etc/profile” for activating an environment without mixing its
environment variables into the current environment. Merging an
environment can be done with “source $profile/etc/profile”. It would be
nice if there was a simpler, unified interface for this.

guix environment --load /my/.guix-profile
guix environment --pure --load /my/.guix-profile
guix environment --container --load /my/.guix-profile

etc.

--
Ricardo
Closed
E
E
Eric Bavier wrote on 16 Feb 2019 17:23
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 34486@debbugs.gnu.org)
20190216102325.3875f22b@centurylink.net
On Fri, 15 Feb 2019 11:42:57 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (22 lines)
> Hello,
>
> This new option allows to specify additional variables to be inherited
> in a “pure” (semi-pure?) environment.
>
> The main motivation was the use of the SLURM batch scheduler, which
> defines environment variables that you need to preserve so that things
> like ‘mpirun’ work correctly.
>
> Thoughts?
>
> Ludo’.
>
> Ludovic Courtès (1):
> environment: Add '--inherit'.
>
> doc/guix.texi | 21 ++++++++++++--
> guix/scripts/environment.scm | 53 +++++++++++++++++++++++++-----------
> tests/guix-environment.sh | 15 +++++++++-
> 3 files changed, 69 insertions(+), 20 deletions(-)
>

I wonder if the word "inherit" here might be too easily confused with
the idea of package inheritance. Could we possibly use an option name
that is familiar? Of-hand I'm thinking of sudo's '-E' and
'--preserve-env'. SLURM itself uses '--export'. Both of these tools
requires passing a list of individual environment variables, but
supporting regexp-matching makes sense to me, especially with the SLURM
use-case in mind.

Now I'm having second thoughts. Since this will be invoked as 'guix
environment --inherit' hopefully the proximity of the word
'environment' will be strong enough to dispell associations with
other types of inheritance.

Anyhow, sending this anyway just to share the concern.

`~Eric
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEoMXjUi7471xkzbfw/XPKxxnTJWYFAlxoOP0ACgkQ/XPKxxnT
JWYmrg//SAqkAqgJPjpEPOVqsVIWitBd7xmpgKZ1gNtWrEkdU+/yWJ1Ua/U+jvxT
O30s7V8Vl8ypv8e8Kk64+ewv9TVs4iKgFray/vR2rUj0HmMIGAPPrTpfh5c8eNwV
DTfrxXK1E0tOBIm2ed0pWKiIaqL+jfDicp62aZp1myDD06lrRhKMl3TGg31f2RvJ
hnp+u5ZU9XW0oFwdO5qOoWvi3ch3sYv3laeVOcSzXhB5S8F05As+ue5AarokiWdP
LZJHIqaO52TaEHId4GuSRYelO5P10i5/p6AelzkeBrC2TeK1xKrAWApkCty0r2m0
7I7y4Vknhlx36EYiR2+loDea2X3h3+Bk5hvtYPJhnXBgVtivynUizxC0BJyQVEX2
y2sGmfc6AjQgeRKHvThdxBc0daCbSHabLnPWc3Gbu4XaUpCBS8ln/RQgELpRymtb
aqmU9ErKtIg+xfFe39i5qIUyo3sUKjpj7EMuIluEKDxnlzzY/f2wpB/QBMoFkEE0
sYBZfUuO629EDD3KDWKea+Sgr/OoQrB046PmcDGw/Gmq79XX0yqTE+0CRmBzKu7d
1jxl5YWeFjXQpSexOa9tABVWa6D5GVNe9HrEfYBJ3idCchLs3Bsrw/VOhmzUPI38
wT+F7b5chG/Xc7VhoGRCxHCvGfTsFlyBPtBhXSVhRH9V0ePPDko=
=GilV
-----END PGP SIGNATURE-----


K
K
Kyle Meyer wrote on 16 Feb 2019 23:45
(address . 34486-done@debbugs.gnu.org)
87imxjwdxk.fsf@kyleam.com
Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (14 lines)
> It doesn’t need to be much. People can “save” environments with
> “--root” but they have no built-in mechanism to “load” an environment
> that has been saved like that.
>
> Loading can be done with “env /path/to/bash --init-file
> $profile/etc/profile” for activating an environment without mixing its
> environment variables into the current environment. Merging an
> environment can be done with “source $profile/etc/profile”. It would be
> nice if there was a simpler, unified interface for this.
>
> guix environment --load /my/.guix-profile
> guix environment --pure --load /my/.guix-profile
> guix environment --container --load /my/.guix-profile

I'd be very excited to see such an interface, especially the last form.
I've been using the 'env ...' approach to work with profiles (say for a
particular project or analysis), but it'd be great to have an easy way
to point to an existing profile and say "use this profile to run this
command in a container".

I'm happy to take a stab at implementing --load (though I might know so
little that I don't realize that that is over my head at the moment :>).

--
Kyle
Closed
L
L
Ludovic Courtès wrote on 18 Feb 2019 23:16
(name . Eric Bavier)(address . ericbavier@centurylink.net)(address . 34486@debbugs.gnu.org)
87va1g91ye.fsf@gnu.org
Hi Eric,

Eric Bavier <ericbavier@centurylink.net> skribis:

Toggle quote (8 lines)
> I wonder if the word "inherit" here might be too easily confused with
> the idea of package inheritance. Could we possibly use an option name
> that is familiar? Of-hand I'm thinking of sudo's '-E' and
> '--preserve-env'. SLURM itself uses '--export'. Both of these tools
> requires passing a list of individual environment variables, but
> supporting regexp-matching makes sense to me, especially with the SLURM
> use-case in mind.

That’s a good point, I did wonder too and spent some time thinking about
the choice of words (“inherit”, “preserve”, “keep”, and more elaborate
phrases) and in the end settled with “inherit”.

Toggle quote (5 lines)
> Now I'm having second thoughts. Since this will be invoked as 'guix
> environment --inherit' hopefully the proximity of the word
> 'environment' will be strong enough to dispell associations with
> other types of inheritance.

Yeah, hopefully.

If it sounds confusing or unclear at first, then perhaps we should
change. What do people think?

Thanks,
Ludo’.
T
T
Thompson, David wrote on 19 Feb 2019 15:33
(name . Ricardo Wurmus)(address . rekado@elephly.net)
CAJ=RwfbL43x5kE6PO6h6+FNgXY3-1wpAZdi+TK2UXQ2PkX37_w@mail.gmail.com
On Sat, Feb 16, 2019 at 4:13 AM Ricardo Wurmus <rekado@elephly.net> wrote:
Toggle quote (24 lines)
>
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
> >> I guess the only thing that’s missing now is to activate an installed
> >> environment.
> >
> > Something beyond --search-paths and etc/profile, right? I’m not sure
> > what it would look like.
>
> It doesn’t need to be much. People can “save” environments with
> “--root” but they have no built-in mechanism to “load” an environment
> that has been saved like that.
>
> Loading can be done with “env /path/to/bash --init-file
> $profile/etc/profile” for activating an environment without mixing its
> environment variables into the current environment. Merging an
> environment can be done with “source $profile/etc/profile”. It would be
> nice if there was a simpler, unified interface for this.
>
> guix environment --load /my/.guix-profile
> guix environment --pure --load /my/.guix-profile
> guix environment --container --load /my/.guix-profile

I never got around to implementing this, but I think we should use
some sane defaults to make 'guix environment' save and load
environments without the user having to figure out a bunch of flags.
For example, running 'guix environment' with no flags should
automatically load up the saved profile in the current directory and
instantiate it. I know about --root, but I never actually use it
because it's kind of a pain. I'd use persistent environments all the
time if it "just worked".

- Dave
Closed
R
R
Ricardo Wurmus wrote on 20 Feb 2019 18:00
(name . Eric Bavier)(address . ericbavier@centurylink.net)
87ef82tmxw.fsf@elephly.net
Eric Bavier <ericbavier@centurylink.net> writes:
Toggle quote (8 lines)
> I wonder if the word "inherit" here might be too easily confused with
> the idea of package inheritance. Could we possibly use an option name
> that is familiar? Of-hand I'm thinking of sudo's '-E' and
> '--preserve-env'. SLURM itself uses '--export'. Both of these tools
> requires passing a list of individual environment variables, but
> supporting regexp-matching makes sense to me, especially with the SLURM
> use-case in mind.

I think “export” is a worse name, especially in combination with “guix
environment”, which sounds like the Guix environment is to be exported.

“preserve” sounds good to me, but it’s also a character longer than
“inherit” ;)

I’m not a big fan of “inherit” because to me it seems to imply that the
existing environment is to be inherited fully, while the actual intent
is to keep only the selected variables.

“keep” or “allow” sound also good to me.

--
Ricardo
L
L
Ludovic Courtès wrote on 4 Mar 2019 11:10
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87tvgjt0eu.fsf@gnu.org
Hi!

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (21 lines)
> Eric Bavier <ericbavier@centurylink.net> writes:
>> I wonder if the word "inherit" here might be too easily confused with
>> the idea of package inheritance. Could we possibly use an option name
>> that is familiar? Of-hand I'm thinking of sudo's '-E' and
>> '--preserve-env'. SLURM itself uses '--export'. Both of these tools
>> requires passing a list of individual environment variables, but
>> supporting regexp-matching makes sense to me, especially with the SLURM
>> use-case in mind.
>
> I think “export” is a worse name, especially in combination with “guix
> environment”, which sounds like the Guix environment is to be exported.
>
> “preserve” sounds good to me, but it’s also a character longer than
> “inherit” ;)
>
> I’m not a big fan of “inherit” because to me it seems to imply that the
> existing environment is to be inherited fully, while the actual intent
> is to keep only the selected variables.
>
> “keep” or “allow” sound also good to me.

So, what about adding ‘--preserve’ (or ‘--keep’? I slightly prefer
“preserve”) and keeping ‘--inherit’ as a deprecated alias?

We could perhaps add ‘-E’ as well, reclaiming the long-deprecated
‘--exec’, WDYT?

Ludo’.
R
R
Ricardo Wurmus wrote on 4 Mar 2019 12:01
(name . Ludovic Courtès)(address . ludo@gnu.org)
87d0n6x5sh.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (28 lines)
> Hi!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Eric Bavier <ericbavier@centurylink.net> writes:
>>> I wonder if the word "inherit" here might be too easily confused with
>>> the idea of package inheritance. Could we possibly use an option name
>>> that is familiar? Of-hand I'm thinking of sudo's '-E' and
>>> '--preserve-env'. SLURM itself uses '--export'. Both of these tools
>>> requires passing a list of individual environment variables, but
>>> supporting regexp-matching makes sense to me, especially with the SLURM
>>> use-case in mind.
>>
>> I think “export” is a worse name, especially in combination with “guix
>> environment”, which sounds like the Guix environment is to be exported.
>>
>> “preserve” sounds good to me, but it’s also a character longer than
>> “inherit” ;)
>>
>> I’m not a big fan of “inherit” because to me it seems to imply that the
>> existing environment is to be inherited fully, while the actual intent
>> is to keep only the selected variables.
>>
>> “keep” or “allow” sound also good to me.
>
> So, what about adding ‘--preserve’ (or ‘--keep’? I slightly prefer
> “preserve”) and keeping ‘--inherit’ as a deprecated alias?

Sounds good to me, though in my opinion “--inherit” hasn’t been around
long enough to warrant deprecation.

Toggle quote (3 lines)
> We could perhaps add ‘-E’ as well, reclaiming the long-deprecated
> ‘--exec’, WDYT?

--preserve/-E would be equivalent?

--
Ricardo
L
L
Ludovic Courtès wrote on 4 Mar 2019 12:14
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87lg1usxfx.fsf@gnu.org
Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (33 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi!
>>
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>>
>>> Eric Bavier <ericbavier@centurylink.net> writes:
>>>> I wonder if the word "inherit" here might be too easily confused with
>>>> the idea of package inheritance. Could we possibly use an option name
>>>> that is familiar? Of-hand I'm thinking of sudo's '-E' and
>>>> '--preserve-env'. SLURM itself uses '--export'. Both of these tools
>>>> requires passing a list of individual environment variables, but
>>>> supporting regexp-matching makes sense to me, especially with the SLURM
>>>> use-case in mind.
>>>
>>> I think “export” is a worse name, especially in combination with “guix
>>> environment”, which sounds like the Guix environment is to be exported.
>>>
>>> “preserve” sounds good to me, but it’s also a character longer than
>>> “inherit” ;)
>>>
>>> I’m not a big fan of “inherit” because to me it seems to imply that the
>>> existing environment is to be inherited fully, while the actual intent
>>> is to keep only the selected variables.
>>>
>>> “keep” or “allow” sound also good to me.
>>
>> So, what about adding ‘--preserve’ (or ‘--keep’? I slightly prefer
>> “preserve”) and keeping ‘--inherit’ as a deprecated alias?
>
> Sounds good to me, though in my opinion “--inherit” hasn’t been around
> long enough to warrant deprecation.

Well, it’s safer and doesn’t cost much to deprecate it properly.

Toggle quote (5 lines)
>> We could perhaps add ‘-E’ as well, reclaiming the long-deprecated
>> ‘--exec’, WDYT?
>
> --preserve/-E would be equivalent?

Yes.

Thanks,
Ludo’.
R
R
Ricardo Wurmus wrote on 4 Mar 2019 12:19
(name . Ludovic Courtès)(address . ludo@gnu.org)
87bm2qx4xn.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (8 lines)
>>> So, what about adding ‘--preserve’ (or ‘--keep’? I slightly prefer
>>> “preserve”) and keeping ‘--inherit’ as a deprecated alias?
>>
>> Sounds good to me, though in my opinion “--inherit” hasn’t been around
>> long enough to warrant deprecation.
>
> Well, it’s safer and doesn’t cost much to deprecate it properly.

True.

Toggle quote (7 lines)
>>> We could perhaps add ‘-E’ as well, reclaiming the long-deprecated
>>> ‘--exec’, WDYT?
>>
>> --preserve/-E would be equivalent?
>
> Yes.

Neat. Let’s do it! :)

--
Ricardo
L
L
Ludovic Courtès wrote on 4 Mar 2019 15:24
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87k1hera3f.fsf@gnu.org
Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (21 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>>>> So, what about adding ‘--preserve’ (or ‘--keep’? I slightly prefer
>>>> “preserve”) and keeping ‘--inherit’ as a deprecated alias?
>>>
>>> Sounds good to me, though in my opinion “--inherit” hasn’t been around
>>> long enough to warrant deprecation.
>>
>> Well, it’s safer and doesn’t cost much to deprecate it properly.
>
> True.
>
>>>> We could perhaps add ‘-E’ as well, reclaiming the long-deprecated
>>>> ‘--exec’, WDYT?
>>>
>>> --preserve/-E would be equivalent?
>>
>> Yes.
>
> Neat. Let’s do it! :)

Done in dca58219584c1163a9fbf88fccea885eb53bf2af, thanks!

Ludo’.
?