feature request: add a flag that tells bazel to include the current environment's variables

[schnaitterm]

I understand the concept of wanting to have a sandboxed environment for builds on many software in order to maintain reproducibility, etc... but the fact that there is no way to tell bazel to do otherwise is an incredible hassle, especially when, for instance, you are using to build software in an HPC environment (cough TensorFlow cough) where everything is managed using environment modules. there should be a flag along the lines of --use-local-env (as in nvcc for CUDA). There's no good reason that I should have to wrap my compilers (Intel, in the current case) just to have them reload all the modules when the compiler is run so that it can find its licenses and what not. I tried using the --action_env option but it had absolutely no effect. We need an option to keep our local environment when building with bazel. Thanks

[nicolov]

You can forward individual environment variables with build --action_env=MYVAR and test --test_env=MYVAR.

[schnaitterm]

As I already said, that did not work and it is not always practical. On Nov 15, 2017 5:46 PM, nicolov <notifications@github.com> wrote: You can forward individual environment variables with build --action_env=MYVAR and test --test_env=MYVAR. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbazelbuild%2Fbazel%2Fissues%2F4093%23issuecomment-344754873&data=02%7C01%7Cschnaitterm%40knights.ucf.edu%7C3ccd28bb9c7d463f20ba08d52c7aaa89%7C5b16e18278b3412c919668342689eeb7%7C0%7C0%7C636463827707659453&sdata=Lh%2BORjuSGvcnKFjaS%2FyTyR3NcKzChYLN6TiQ5Be7ib0%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJOJLi7MHG6kdazjCwcSSQEC4LpNEFIbks5s22mxgaJpZM4Qd83t&data=02%7C01%7Cschnaitterm%40knights.ucf.edu%7C3ccd28bb9c7d463f20ba08d52c7aaa89%7C5b16e18278b3412c919668342689eeb7%7C0%7C0%7C636463827707659453&sdata=jq1ll%2BOrN9Rk%2BA%2Br%2F6cik7yhH165jRrKfpLKeAZloak%3D&reserved=0>.

[benjaminp]

The C++ rules roll their own environment handling and thus have inconsistent behavior with --action_env. That's definitely a bug. #3320 is the meta issue for that.

If you've already managed to set the right env vars for CUDA once doesn't seem like it should be hard to copy that knowledge into the Bazel command line. At the very worst, you can have a Bazel wrapper that translates env into --action_env arguments. Blindly leaking all environmental state into builds is pretty smelly, so I'm not sure Bazel should support it.

[schnaitterm]

@benjaminp that's why it should be an optional flag, but not the default behaviour. and the mentioning of CUDA was only an example of software that implements such a feature. Wrapping env into --action_env arguments is messy and would be stupid to make necessary, when this is functionality the software should have to begin with. If you are going to have a non-standard build system, it should at the very least of the option of doing certain things in a way that at least resembles standard. Bazel, so far, has proven to me to be unwieldy, convoluted, and downright confusing. I wouldn't use it if I didn't need to build software that depended on it

[aiuto]

We would not want to add an option that simply forwards every environment variable. That would mean completely irrelevant variables (e.g. WINDOWID) would impact your build. Caching would be impossible. The only reasonable feature is where the user explicitly enumerates the set of variables they wish to pass on. action_env still seems the right way to approach this. We first have to fix things like #3320, but that is
time well spent anyway.

The first step beyond that would be try try expanding in the .bazelrc
build --action_env=MYVAR=${MYVAR}
If that does not work today, it is certainly a useful feature to add.

If not, one could roll their own interim solution.

• wrapper script around bazel that creates bazel_env.inc, whose content is
  build --action_env=VAR=val
  for each VAR in the list of ones you want to export
• have your .bazelrc import bazel_env.inc.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 3 years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!