aloof-angle-91616
09/30/2020, 3:02 PMSubsystem
subclass EnvironmentPropagator
which doesn't register any options itself, but allows environment variables in the form PANTS_PEX_*
to be converted to just PEX_*
environment variables when we go to run a process (where PEX
is the value of a class-level string field EnvironmentPropagator.environment_sub_component
. making this a subsystem (or not, and using some other method) means we could hook it up to ./pants help
and allow the user to see what variables are in their environment which would affect a pants execution, and we could also incorporate the tool's own help text for its environment variables.
posting here because i made the comment specifically regarding using this for pex in the issue, and i want to see what response i get to that before trying to make a more general issueenough-analyst-54434
09/30/2020, 4:17 PMaloof-angle-91616
09/30/2020, 4:23 PM--verbosity
in the totally separate PexEnvironment
subsystem? i am also somewhat interested in the idea of displaying the options that are available in ./pants help
, as well as pulling the env vars help output from pex itself (since it's mostly trivial to use pex to pull down the version of pex that pants is using, then invoking its help in the command line, but not entirely trivial)# TODO: We may want to support different sets of env vars for different types of process.
# Can be done via scoped subsystems, possibly. However we should only do this if there
# is a real need.