wonderful-iron-54019
08/18/2020, 5:10 PMENV1=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 nowwonderful-iron-54019
08/18/2020, 5:11 PMwonderful-iron-54019
08/18/2020, 5:30 PMhundreds-father-404
08/18/2020, 5:34 PMENV1
a Pants option like PANTS_PYTEST_VERSION
or it’s an env var used by your tests?wonderful-iron-54019
08/18/2020, 5:35 PMhundreds-father-404
08/18/2020, 5:41 PMwonderful-iron-54019
08/18/2020, 5:42 PMwonderful-iron-54019
08/18/2020, 5:42 PMwonderful-iron-54019
08/18/2020, 5:42 PMhundreds-father-404
08/18/2020, 5:51 PMwonderful-iron-54019
08/18/2020, 5:52 PMwonderful-iron-54019
08/18/2020, 5:53 PMwonderful-iron-54019
08/18/2020, 5:53 PMhundreds-father-404
08/18/2020, 5:53 PMpants.toml
, and then append to them on the CLI too.
# pants.toml
[pex]
extra_env = ["PERMANENT=val"]
./pants --pex-extra-env="TEMP=val" test ...
hundreds-father-404
08/18/2020, 6:01 PMout 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 #C0D7TNJHL, 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.