test(integration): reproduce cross-runtime py_binary launch breakage

[misty-fungus]

This commit adds integration test that checks if py_binary is self-contained.

• build parent against python 3.12
• build child against python 3.11
• attach child as data (runtime) dependency to parent
• try to execute child from parent with subprocess

Expected behavior:

Launching child from parent should work the same as launching child
directly. The rules_python launcher should preserve the child's runtime
isolation and should not depend on incompatible import paths inherited from the
parent process.

Observed behavior:

Setting PYTHONPATH in parent breaks the child launch.

Two test cases launch child with sys.executable interpreter and as a standalone program. In both cases we have a crash in stage1 and stage2 bootstrap scripts respectfuly.

Documentation lacks information about py_binary middleman's guarantees and correct way of PYTHONPATH handling. Shall we either document or make a fix?

[gemini-code-assist]

Code Review

This pull request introduces a new integration test suite, sys_executable_cross_runtime, which evaluates scenarios where a parent Python process (version 3.12) executes a child Python process (version 3.11) while inheriting the parent's PYTHONPATH. This is intended to reproduce and test potential conflicts in runtime import paths across different Python versions. The review feedback highlights that using sys.executable to launch a Bazel py_binary is fragile, as the binary is often a shell script launcher on Unix platforms, which would result in a SyntaxError if executed directly by the Python interpreter.

I am having trouble creating individual review comments. Click here to see my feedback.

tests/integration/sys_executable_cross_runtime/parent.py (22)

Using sys.executable to run a py_binary output is fragile because the output format of a Bazel Python binary is an implementation detail. On Unix platforms, it is typically a shell script launcher, which will cause a SyntaxError if executed directly by the Python interpreter. While this might be intended to reproduce a specific failure mode in the bootstrap scripts, it is generally safer to execute the binary directly.