wonderful-iron-54019
08/18/2020, 7:00 PMwitty-crayon-22786
08/18/2020, 7:04 PMwonderful-iron-54019
08/18/2020, 7:05 PMwitty-crayon-22786
08/18/2020, 7:05 PM$ env | grep LaunchInstance
LaunchInstanceID=BFA89F91-2DC0-4950-BA60-5670917DE455
wonderful-iron-54019
08/18/2020, 7:07 PMwitty-crayon-22786
08/18/2020, 7:08 PMhundreds-father-404
08/18/2020, 7:10 PM--pex-extra-path=['FOO', 'BAR']
, and that would signal to read from os.env
, rather than having to set 'FOO="${FOO}"
You could also explicitly set the env var if you want.
(Either way, I think this is a better design than the proposal)witty-crayon-22786
08/18/2020, 7:10 PMhundreds-breakfast-49010
08/18/2020, 7:18 PMhundreds-father-404
08/18/2020, 7:20 PMwonderful-iron-54019
08/18/2020, 7:21 PMhundreds-breakfast-49010
08/18/2020, 7:23 PMwitty-crayon-22786
08/18/2020, 7:23 PMrun
and repl
are in the foreground, and don’t need this setting at all… should just be able to use any env vars without a setting.hundreds-father-404
08/18/2020, 7:24 PM--pex-executable-search-paths
might be the wrong place for where you control the $PATH env var. Consider if you are using a Protobuf plugin and that for some reason needs to discover something via the $PATH.
I wonder if that option should apply to everywhere.witty-crayon-22786
08/18/2020, 7:25 PMhundreds-father-404
08/18/2020, 7:26 PMoh. but the (original) usecase was during pex building? ie to pass to PEX/pip?Yeah, the original motivating case was so that a test could consume the env var. Which might imply we want a
--pytest-extra-env
optionwitty-crayon-22786
08/18/2020, 7:27 PMhundreds-father-404
08/18/2020, 7:28 PMwitty-crayon-22786
08/18/2020, 7:28 PMhundreds-father-404
08/18/2020, 7:28 PMtest
for now, as it’s easier to loosen things than to take away functionality. So long as that solves JP’s issuewitty-crayon-22786
08/18/2020, 7:29 PMtox
uses?hundreds-father-404
08/18/2020, 7:30 PMtox
is what inspired the allowlist shorthand. I think they have separate settings for literal vals vs. allowlist iirc, though