https://pantsbuild.org/ logo
Join Slack
Powered by
Looks like when running a PEX I can access environ...
# general
h
Looks like when running a PEX I can access environment variables. Wondering if there is a way to have pants add variables to the environment when running a PEX. Also wondering if it can be done in a way that is user specific. Something like how gradle handles local.properties. The specific use case I'm thinking of is when there is a utility that requires sensitive information. Perhaps a utility that requires a username and password. Only certain users should have the credentials and they shouldn't be added to source control. Users with access might have something like a .pants file containing the environment variables, which is ignored by git. Anything like this exist?
h
Hmm, the 
env_vars
option in the 
[subprocess-environment]
scope allows you to set some env vars, but they have to be in a specific allowlist (see 
./pants help-advanced subprocess-environment
)
Also when running tests you can use 
extra_env_vars
in the 
[test]
scope to set arbitrary env vars in the test's process
But I don't think there's a way to set arbitrary env vars on non-test processes. Wouldn't be hard to add though.
Oh, just realized I might be misunderstanding. Are you referring to setting env vars when Pants runs a pex file as part of its own operation, or somehow "baking" env vars into the pex files it creates when you run 
./pants package
?
h
I think the former. So I don't want to bake them in. I'll make up a totally fictitious example. When developer A runs ./pants run utilities:generate it see a file named .pants_local containing a list of properties that are turned into environment variables. In this case the file might contain the user name and password for developer A's local database. Developer B also has a .pants_local file that has their specific properties. Neither A's or B's .pants_local file would get committed to source control. If the utility were deployed into production there would be no .pants_local file and the production user name and password would come from the production environment.
h
I see, so it's specifically for 
./pants run
?
When asking pants to run your own code
That seems very reasonable to add, let me take a look
h
Wow you guys are quick.
h
@happy-kitchen-89482 the run goal already intentionally leaks in all env vars; we don't scrub it. Are you seeing differently @high-egg-2153?
h
Yes, I was seeing that environment variables are available. The difference with the solution as I understood it was that now I could specify additional environment variables in a file that would get added to the run environment. That way each developer could have a local file with their specific variables.
h
Ah I see, that makes sense
Before we hit merge, have you heard of direnv? I'm wondering if that might work instead for your use case? (I think we prob want this PR either way, but trying to stress test it)
h
Nope - but that could potentially give me what I was asking for.
h
I think we will still want this because it allows you to hardcode env vars in pants.toml, which could be useful. Plus parity with the test goal
👍 1
h
I was unaware that we passed in the entire Pants env, although that makes sense.
h
h
So the "inherit this value from the environment" variant is redundant in this case
👍 1
Possibly my change is not necessary then, if direnv can work
although I guess it might be nice to support the 
@fromfile
syntax more directly.
4 Views
Open in Slack
PreviousNext
Powered by