another question about moving from 1.29 -> 1.30...
# general
w
another question about moving from 1.29 -> 1.30 seems like my env vars sett like
ENV1=val1 ENV2=val2 ./pants test src::
is no longer being respected, as im getting a lot of
ValueError: 'ENV1' is a required config value
in my tests now
any reason why this might be the case? should i no longer expect pants to carry over environment set in the parent process?
happy to open an issue if not
h
Hm. Are you using the v1 test runner or v2 test runner here? Is
ENV1
a Pants option like
PANTS_PYTEST_VERSION
or it’s an env var used by your tests?
w
v1 at the moment, and the latter scenario
h
I’m looking through the changelog. We’ve barely touched v1 in months, so I’m unclear what would cause this regression
w
im clearly triggering it by changing my pants version
👍 1
maybe a transitive dependency
wil also try with. a clean source tree just in case
h
Still looking. Your use case also points to a use case we need to support in 2.0: setting arbitrary env vars in CI, while still preserving the overall hermiticity we desire. I opened https://github.com/pantsbuild/pants/issues/10644 How does that proposal sound?
w
yeah that's perfect, we'll just move the env vars from the. front to the back of the command
❤️ 1
out of curiousity, any consideration to an option to preserve. the original environment in its entirety when creating new run envs for pex?
seems like that. would still qualify as hermetic
h
Awesome. And list options are nice that you can permanently configure certain env vars in your
pants.toml
, and then append to them on the CLI too.
Copy code
# pants.toml
[pex]
extra_env = ["PERMANENT=val"]
./pants --pex-extra-env="TEMP=val" test ...
Be back in ~45 minutes or so, meeting.
out of curiousity, any consideration to an option to preserve. the original environment in its entirety when creating new run envs for pex?
Would you mind posting that in #engine, please? I’m curious what others would think. It’s technically possible, although opens up the flood gates for reducing reproducibility, such as increasing the risk of Works On My Machine errors. Also it would be a weird interaction with things like how
--pex-interpreter-search-paths
already controls the $PATH env var. But like everything, there’s a tradeoff there, and perhaps the usability win justifies the loss to reproducibility and hermiticity.