You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something it's very convenient to do a quick singularity shell or singularity exec with the container - which requires to know where the image is. Having the module define an environment variable would make this easier. Something along the lines of
pushenv("NGC_IMAGE", image)
would make it a lot easier to say singularity shell --nv $NGC_IMAGE (compared to a "which myprogram-followed-by-copy-pasting-of-the-container-path-from-the-alias").
Granted, this would get a little more complicated when image = uri (name will be different when singularity pulls), but it can be handled too, right?
The text was updated successfully, but these errors were encountered:
Good point. Something like BASH_SOURCE or BASH_FUNC arrays could be handy, but not all shells support arrays.
So we could take two approaches with this: either "the variable always holds image name for last loaded container module", or "the variable is PATH-style with colon-separated image names as they are loaded".
Something it's very convenient to do a quick
singularity shell
orsingularity exec
with the container - which requires to know where the image is. Having the module define an environment variable would make this easier. Something along the lines ofwould make it a lot easier to say
singularity shell --nv $NGC_IMAGE
(compared to a "which myprogram
-followed-by-copy-pasting-of-the-container-path-from-the-alias").Granted, this would get a little more complicated when
image = uri
(name will be different when singularity pulls), but it can be handled too, right?The text was updated successfully, but these errors were encountered: