Uh oh!
There was an error while loading. Please reload this page.
feat: inherit PYTHONSAFEPATH env var from outer process - #2076
Conversation
7687eb7 to
f730df0Compare…o feat.allow.env.override
allsey87
commented
Jul 19, 2024
I will check if this solves #2060, but I have a hunch that just setting |
rickeylev
commented
Jul 19, 2024
One of the tests does exactly that and checks the interpreter flag to verify that safe path is disabled, so it should work :). Feel free to re-open the issue with a repro if you find otherwise. Actually, I'm going to re-open the issue for now. This only fixes it for --bootstrap_impl=script, not windows, and, come to think of it, certain types of zips might also still have the bug. |
rickeylev
commented
Jul 19, 2024
Doh, this introduced a bug that disable safe path by default unless it was opted in to. That'll be fixed shortly in #2073. |
Previously, all the user import paths were put at the end of sys.path. This was done so that user import paths didn't hide stdlib modules. However, a side-effect is that user import paths came after the runtime's site-packages directory. This prevented user imports from overriding non-stdlib modules included in a runtime (e.g. pip). To fix, we look for the runtime site-packages directory, then insert the user import paths before it. A test is used to ensure that the ordering is `[stdlib, user, runtime site-packages]` Also fixes a bug introduced by #2076: safe path was being disabled by default Fixes#2064
By default, PYTHONSAFEPATH is enabled to help prevent imports being found where they
shouldn't be. However, this behavior can't be disabled, which makes it harder to use
a py_binary when the non-safe path behavior is explicitly desired.
To fix, the bootstrap now respects the caller environment's PYTHONSAFEPATH environment variable, if set. This allows the callers to set
PYTHONSAFEPATH=(empty string) tooverride the default behavior that enables it.
Fixes#2060