Consider hpcng #6211 (Remove environment variables eval for --bind, --nv and --rocm for build command)

[dtrudg]

apptainer/singularity#6211

This is marked up as fixing apptainer/singularity#6181 but it does not. They consider the main topic of the issue a wontfix.

The PR actually addresses a distinct observation / request from a comment on that issue at apptainer/singularity#6181 (comment)

The addition in 3.8 of the --bind / --nv / --rocm flags to the singularity build command currently also means that the SINGULARITY_BINDPATH / SINGULARITY_NV / SINGULARITY_ROCM environment variables can affect the build, as they provide a way of setting the same behavior as the flags.

The issue commentor is suggesting that these are runtime settings and should not affect a build process. The hpcng PR is removing the environment variables from consideration under singularity build only. They remain for run / shell / exec etc.

I personally view this as a preference, rather than a bug. If we have flags of the same name that can take an env var value under some circumstances, and not others, then that is rather confusing.

Administrator set SINGULARITY_BINDPATH env vars etc. (via modulefiles or global profiles) are likely quite rare. So, I'm not sure it'll be common at all for users to need to unset these when running a build. We'd encourage administrators to set those things via the singularity.conf directives instead, where they won't affect the build. Additionally, builds are often run under a sudo call which will drop the env vars (without -E) anyway.

Any thoughts on this one @tri-adam ?

I'm inclined to address the original hpcng#6211 issue, tbh. If you request a --bind in a build then we should be able to create the bind destination in the image under build that is necessary, automatically. Though, I'm not completely convinced that binding arbitrary things in during a build is universally a good thing. With a sudo singularity build being common, it's an extra way to impact your host accidentally (over and above the %setup block).

[tri-adam]

I personally view this as a preference, rather than a bug. If we have flags of the same name that can take an env var value under some circumstances, and not others, then that is rather confusing.

Yeah, agreed. the least surprising behaviour is likely for the flags work the same as the (equivalent) environment variables for build/exec contexts.

Administrator set SINGULARITY_BINDPATH env vars etc. (via modulefiles or global profiles) are likely quite rare. So, I'm not sure it'll be common at all for users to need to unset these when running a build. We'd encourage administrators to set those things via the singularity.conf directives instead, where they won't affect the build. Additionally, builds are often run under a sudo call which will drop the env vars (without -E) anyway.

Perhaps something to address via documentation...

I'm inclined to address the original hpcng#6211 issue, tbh. If you request a --bind in a build then we should be able to create the bind destination in the image under build that is necessary, automatically. Though, I'm not completely convinced that binding arbitrary things in during a build is universally a good thing. With a sudo singularity build being common, it's an extra way to impact your host accidentally (over and above the %setup block).

Yeah, pros and cons to this approach...

[dtrudg]

Going to close this one unless we have the same request from multiple people. I still don't like the idea of an env var and flag being connected in some places, and not others,