PEX runtime warnings should have a knob to squelch

[jsirois]

I'm not sure the knob should default on or off, but some from of warning control makes sense since once a pex is built, it will emit this warning on every run which does not seem useful past the first time a human acknowledges the issue - which they may not even be able to fix easily if due to 3rdparty deps.

[Eric-Arellano]

I’d propose turning on by default, and making it very clear how to turn it off. If we default to off, I’m concerned few would discover it’s even an option.

For the 3rd party dependency issue, if we default to the messages being on then we may need a way to silence the errors other than a CLI flag to PEX, such as using an env var.

[jsirois]

Since these are runtime warnings, we can't really use a flag unless we co-opt -W from python like we did -c, and -m, but even then that only works if the pex is run in interpreter mode since we can't otherwise steal argv. An env var seems to be all that remains then and isn't awesome from an ergonomics perspective since you have to always run the pex with the env var to get the desired effect; ie: the solution is not self-contained. Perhaps adding a build-time option and embedding the choice in PEX-INFO would be good enough:

1. Build the pex
2. Run it and notice warning you can't do anything about short-term
3. Re-build the pex with --no-emit-warnings
4. If you actually want to see warnings now you have to PEX_EMIT_WARNINGS=1 ./pex.

[Eric-Arellano]

I agree env var is not ergonomic. We certainly wouldn’t expect someone to have to permanently source it from their .bashrc or anything, which would mean always having to remember to set it.

I like the build time option the most. I like it because it has a sensible default and will provide instructions for how to turn it off permanently for that PEX. The decision is also per-PEX, in that you might want to silence for one but keep for another, which is good to not assume the user wants something global.