| Message ID | 20190215104257.16275-1-ludo@gnu.org |
|---|---|
| Headers | show |
| Series | Add '--inherit' to 'guix environment' | expand |
Hi, 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: --8<---------------cut here---------------start------------->8--- #!/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" --8<---------------cut here---------------end--------------->8--- I guess the only thing that’s missing now is to activate an installed environment. -- Ricardo
Hello, Ricardo Wurmus <rekado@elephly.net> skribis: > 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. > 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’.
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 etc. -- Ricardo
On Fri, 15 Feb 2019 11:42:57 +0100 Ludovic Courtès <ludo@gnu.org> wrote: > 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
Ricardo Wurmus <rekado@elephly.net> writes: > 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 :>).
Hi Eric, Eric Bavier <ericbavier@centurylink.net> skribis: > 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”. > 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’.
On Sat, Feb 16, 2019 at 4:13 AM Ricardo Wurmus <rekado@elephly.net> wrote: > > > 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
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. -- Ricardo
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? We could perhaps add ‘-E’ as well, reclaiming the long-deprecated ‘--exec’, WDYT? Ludo’.
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. > We could perhaps add ‘-E’ as well, reclaiming the long-deprecated > ‘--exec’, WDYT? --preserve/-E would be equivalent? -- Ricardo
Ricardo Wurmus <rekado@elephly.net> skribis: > 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. >> We could perhaps add ‘-E’ as well, reclaiming the long-deprecated >> ‘--exec’, WDYT? > > --preserve/-E would be equivalent? Yes. Thanks, Ludo’.
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! :)
Ricardo Wurmus <rekado@elephly.net> skribis: > 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’.