New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Singularity and environment variables and 3.6.0 proposal #5040
Comments
A few questions! Envar Preference
Does this mean that a previously defined FOO is overwritten (this would be my expectation, if I explicitly set a SINGULARITYENV_* variable I'd want it to override. Also, does this mean I can unset a defined variable by leaving it empty (e.g., Environment external filesIt's fairly common to want to set envars at runtime, especially with secrets and what not. What about instead of requiring a bunch of custom SINGULARITYENV_* there is some simple support for an environment file? For example, if you just bind a file to be inside the env folder, this should work as expected. This could have a nice wrapper to do this, so for the client something like: singularity run --env-file myenv.sh container.sif And actually you could mirror Docker and add the --env flag (this would be very intuitive) singularity run --env MINNIE=MOUSE container.sif FeebackOkay taking a look at last section (there is already overlap with my suggestions above!) For this bit:
We'd just want to make sure that you can also do:
To unset the variable.
This won't come naturally to writing recipes, so this should be all over the docs, and even current recipes/example updated to explain it. Question : You mentioned Overall, it's really great that attention is being placed on hardening this up! I am reviewing this from the standpoint of a typical user, that likely won't even delve into the tricks of using SINGULARITYENV_*, but perhaps would be comfortable with the idea of a file of environment variables ( |
It depends of the workflow in the runtime and need to be defined to establish clear rules.
Can't answer right now, also depends of the workflow
|
@vsoch #5028 is ready for experiment, I think it addresses your comments, so your feedbacks would be much appreciated, thanks ! In its current status :
The action script sourcing do :
|
I'm reopening this as I'm referring to it in discussion in various places. We can close once we are both stable and documented. |
I am really happy with the idea of putting --env-file !! Currently there is some other way to do the same trick for many variables ? The only solutions I found so far is writing a long script full of SINGULARITYENV_* one after the other. Thanks for the help. |
Hi @alchemroz - there isn't a way to do this on the current stable release. The 3.6 release with then |
To resume how things works actually
Singularity forward host user environment variables to container process in various inconsistent and not reproducible ways.
Variables always forwarded from host user environment to container process no matter if
--cleanenv
is specified or not:term
(case insensitive)http_proxy
(case insensitive)https_proxy
(case insensitive)no_proxy
(case insensitive)ftp_proxy
(case insensitive)Variables never forwarded from host user environment to container process:
path
(case insensitive)ld_library_path
(case insensitive)Default variables always forwarded but impossible to override from CLI:
HOME
by default uses home directory defined in user database or the source part from--home
optionPATH
always set to"/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin"
LANG
set to "C" when--cleanenv
is specifiedVariables prefixed with
SINGULARITYENV_
see their prefix trimmed and are forwarded to container process no matter if--cleanenv
is specified or not:SINGULARITYENV_FOO
becomeFOO
in container process :--cleanenv
is not set leading to inconsistenciesThere is few exceptions for
SINGULARITYENV_
variables :SINGULARITYENV_PREPEND_PATH
becomeSING_USER_DEFINED_PREPEND_PATH
SINGULARITYENV_APPEND_PATH
becomeSING_USER_DEFINED_APPEND_PATH
SINGULARITYENV_PATH
becomeSING_USER_DEFINED_PATH
All variables forwarded to container process goes through an environment setup before executing the real container process and it's done with sourced scripts located in
/.singularity.d/env
within the container image:/.singularity.d/env/01-base.sh
(nothing done in this script)/.singularity.d/env/10-docker2singularity.sh
(contains environment variables defined in Dockerfile if any)/.singularity.d/env/90-environment.sh
(content of%environment
section if build from a definition file)/.singularity.d/env/91-environment.sh
(optional and depend of$SINGULARITY_ENVIRONMENT
use)/.singularity.d/env/94-appsbase.sh
(contains related app environment variables)/.singularity.d/env/95-apps.sh
(append bin/lib apps path inPATH
andLD_LIBRARY_PATH
)/scif/apps/${SINGULARITY_APPNAME}/scif/env/01-base.sh
/scif/apps/${SINGULARITY_APPNAME}/scif/env/90-environment.sh
(content of app%appenv
section)/.singularity.d/env/99-base.sh
(adds/singularity.d/libs
toLD_LIBRARY_PATH
and forcePS1="Singularity> "
)/.singularity.d/env/99-runtimevars.sh
(handle specialSING_USER_DEFINED_
path variables)Important consideration: until Singularity 3.1.0 all images bootstrapped from docker translated
ENV KEY val
Dockerfile lines to the export formexport KEY=VAL
, since 3.1.0 they are translated toexport KEY=${KEY:-"VAL"}
to be overridable, those exported variables are located in container image at:/.singularity.d/env/10-docker2singularity.sh
for v3/.singularity.d/env/10-docker.sh
for v2With all the above in mind let's take an example with an image run from
docker://golang:1.13
, thethe Dockerfile of this image has defined environment variables:
When running with Singularity prior to 3.1.0:
Because it's always forced by
/.singularity.d/env/10-docker2singularity.sh
containingexport GOPATH=/go
When running with Singularity >= 3.1.0:
Because
/.singularity.d/env/10-docker2singularity.sh
containsexport GOPATH=${GOPATH:-"/go"}
allowing to overrideGOPATH
from the forwarded variable.Now if we build the image with the following definition file:
The container image now contains a
/.singularity.d/env/90-environment.sh
with the content:Obviously with any Singularity version
GOPATH
is not overridable anymoreProposal for consistency and rules in 3.6.0
No changes regarding forwarding of user host environment variables
SINGULARITYENV_
are passed to:/.singularity.d/env/10-docker2singularity.sh
or/.singularity.d/env/10-docker.sh
/.singularity.d/env/90-environment.sh
/.singularity.d/env/91-environment.sh
--env
option to pass environment variables by simply prefixing them withSINGULARITYENV_
--env PYTHONPATH=/python/path:\${PYTHONPATH}
Rules:
%environment
section are overridable only if the image author allow it:The text was updated successfully, but these errors were encountered: