Define PLZ_ENV in build environments
#3444
Merged
+5
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It would be useful for executables to be able to tell whether they are running within a Please build environment, whether or not that environment is sandboxed. One definitive use case is when deciding whether or not resources should be loaded from
$TMP_DIR, which has a special (and well-defined) meaning within a Please build environment but not outside of one, even though the variable may still be defined in the environment. The java-rules and python-rules plugins would both benefit from this, given thatjava_binaryJARs andpython_binarypexes have runtimes that are expected to be discovered dynamically but will be located at different paths depending on whether they are executing underplz test(inside a build environment) orplz run(outside a build environment).Define the
PLZ_ENVvariable in Please build environments. This of course does not guarantee that the environment was created by Please, but is a better indicator of that than heuristics such as testing for the presence of other variables that happen to be defined in certain build environments, such asBUILD_CONFIGand_TEST_ID.