-
-
Notifications
You must be signed in to change notification settings - Fork 636
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
Add global option process_extra_env
for every Process call
#21501
base: main
Are you sure you want to change the base?
Conversation
Thanks for tackling this! So we actually already have an option for this: https://www.pantsbuild.org/dev/reference/subsystems/subprocess-environment The problem is that we only actually apply those env vars in some Python-related processes. But the documentation of that option is very clear that it should apply to all processes. So this is simply broken today. Therefore, instead of the new option, could you make this existing option apply to all processes, and remove the special handling in the python cases? This would also close #16565 . |
@benjyw I'm getting a bunch of rule errors. It looks like SubprocessEnvironment uses EnvironmentAware class which afaik needs an EnvironmentName which means that I can't use it in the |
process: Process, process_execution_environment: ProcessExecutionEnvironment | ||
process: Process, | ||
process_execution_environment: ProcessExecutionEnvironment, | ||
env_vars: SubprocessEnvironmentVars, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your rule needs to request a SubprocessEnvironment.EnvironmentAware
I believe. That is the trick by which different environments can set different env vars (and more generally is the trick by which different environments can have different values for a subsystem).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't work, because I have to Get(EnvironmentVariables) inside to get the actual values, and it still fails with a missing rule. 26f69bf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, yes, you were doing the right thing to begin with, I read SubprocessEnvironmentVars
as SubprocessEnvironment
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The get_subprocess_environment
rule takes care of going from SubprocessEnvironment.EnvironmentAware
to actual dict of env vars.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take a closer look in a bit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh boy, yes, this is more complicated than I first appreciated.
However, the complication is justified, and adding a new option won't solve it, unless the new option is not EnvironmentAware, which seems simply incorrect.
I will noodle on this a bit more.
I've asked @stuhood to take a look at this, as his engine expertise is second to none. |
Thank you! |
Precompiled binaries that were not created for NixOS usually have a so-called link-loader hardcoded into them. On Linux/x86_64 this is for example /lib64/ld-linux-x86-64.so.2. for glibc. NixOS, on the other hand, usually has its dynamic linker in the glibc package in the Nix store and therefore cannot run these binaries.
The solution is to use
nix-ld
, but it only works if you setNIX_LD
env variable for every process call.This pr adds a global option
process_extra_env
to set arbitrary env variables for every pants Process call.