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?

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

)

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.

I see, so it's specifically for

./pants run

?

Wow you guys are quick.

@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?

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.

Ah I see, that makes sense

Nope - but that could potentially give me what I was asking for.

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

I was unaware that we passed in the entire Pants env, although that makes sense.

yeah formalized in https://github.com/pantsbuild/pants/pull/10701

So the "inherit this value from the environment" variant is redundant in this case