Testing

[vkarampudi]

Fix Bazel PEP 517 Build Environment Isolation and Sandbox Restrictions

Problem

When building tensorflow-data-validation from source inside PEP 517 isolated build environments (e.g., standard pip install without flags), the installation fails during wheel compilation.

Modern Bazel runs repository rules (like local_python_configure) under a strictly hermetic environment. This process strips out custom environment variables—including the temporary PYTHONPATH and PYTHON_BIN_PATH created by pip's build isolation. As a result:

1. Bazel queries the host's global Python interpreter instead of the isolated venv's Python binary.
2. Bazel fails to import numpy (which was installed in the isolated build environment), raising:
   ModuleNotFoundError: No module named 'numpy'
3. A secondary issue occurs where Bazel's repository_ctx.execute() does not propagate environmental configurations down to its spawned subprocesses, causing further sandbox resolution failures.

Solution

This change propagates the isolated pip build environment dynamically across the Bazel sandbox boundaries:

1. Propagate Environment Variables via --repo_env:
   Updated setup.py to dynamically propagate PYTHONPATH (including virtualenv paths from sys.path) and PYTHON_BIN_PATH into Bazel commands using --repo_env.
2. Cross the Sandbox Barrier:
   Added PYTHONPATH to the _ENVIRONS list of the local_python_configure rule in third_party/python_configure.bzl to allow it to cross the repository sandbox boundary.
3. Explicit Subprocess Environment Propagation:
   Modified _raw_exec in third_party/python_configure.bzl to explicitly inherit PYTHONPATH, PYTHON_BIN_PATH, and PYTHON_LIB_PATH from repository_ctx.os.environ and pass them down via the environment parameter of repository_ctx.execute().

Impact

Enables seamless out-of-the-box PEP 517 isolated compilation and source wheel builds of tensorflow-data-validation across all supported Python versions (including Python 3.13).