Run interpreter discovery under -I mode

[charliermarsh]

Summary

If you have a file typing.py in the current working directory, python -m doesn't work in some Python versions:

❯ python -m foo
Could not import runpy module
Traceback (most recent call last):
  File "/Users/crmarsh/.local/share/rtx/installs/python/3.9.18/lib/python3.9/runpy.py", line 15, in <module>
    import importlib.util
  File "/Users/crmarsh/.local/share/rtx/installs/python/3.9.18/lib/python3.9/importlib/util.py", line 2, in <module>
    from . import abc
  File "/Users/crmarsh/.local/share/rtx/installs/python/3.9.18/lib/python3.9/importlib/abc.py", line 17, in <module>
    from typing import Protocol, runtime_checkable
ImportError: cannot import name 'Protocol' from 'typing' (/Users/crmarsh/workspace/uv/typing.py)

This did not cause problems for us on Python 3.11 or later, because we set PYTHONSAFEPATH, which avoids adding the current working directory to sys.path. However, on earlier versions, we were failing with the above. (It's important that we run interpreter discovery in the current working directory, since doing otherwise breaks pyenv shims.)

The fix implemented here uses -I to run Python in isolated mode, which is even stricter. The downside of isolated mode is that we currently rely on setting PYTHONPATH to find the "fake module" that we create on disk, and -I means PYTHONPATH is totally ignored. So, instead, we run a script directly, and that script injects the path we care about into PYTHONSAFEPATH.

Closes #2547.

[charliermarsh]

I don't understand why this broke the Windows shims.

[charliermarsh]

I guess the bat doesn't like a multi-line script argument... Very weird.

[charliermarsh]

I also manually verified that the Pyenv shims continue to work:

DEBUG Starting interpreter discovery for default Python
DEBUG Probing interpreter info for: /Users/crmarsh/.pyenv/shims/python3
DEBUG Found Python 3.10.2 for: /Users/crmarsh/.pyenv/shims/python3
Using Python 3.10.2 interpreter at: /Users/crmarsh/.pyenv/versions/3.10.2/bin/python3
Creating virtualenv at: .venv
Activate with: source .venv/bin/activate

[zanieb]

Interesting. Why -c (and previously -m) instead of just python <path>?

[charliermarsh]

We need to be able to resolve relative imports (so we can't use python <path>), but we can't use -m because the module we want to run isn't in sys.path until we modify it. So complicated.