Gladly.

So imagine you have the following files:

- foobar
  - pyfoo
    - foo.py
    - src
      - test
        - bar.py

Since Bazel is a build system, you declare (in directory foobar):

py_library(
  name = "foo", # abstract name
  imports = ".",
  srcs = ["pyfoo/foo.py"], # Which source files are in that library
)

py_test(
  name = "bartest",
  srcs = ["pyfoo/src/test/bar.py"], # The test script
  deps = ["foo"], # "Will import foo" -> import of foo's parent directory is added when executing test
)

Bazel does not ship with a specific Python version. So you (the user) start Bazel and provide it with a path to a Python on your system. This means that the Python version MAY be different on every execution of Bazel.

Then you can use Bazel to execute the bartest.
Bazel will create a temporary directory (as a bit of sandboxing) and copy all declared files (+ directories) into it. Bazel will execute the provided Python binary and try set PYTHONPATH so that a import foo does work (notice the imports declaration above).
This is the part where I think a ._pth alongside the script would be beneficial, because for every test invocation the paths will be different. And multiple tests may be executed in parallel (so a "global" ._pth does not cut it). Using a ._pth one could get around setting an environment variable.


Now to simplify deployment I want to put an embeddable Python alongside Bazel and always tell it to use this one. With Embeddable, the only way I have to modify sys.path is to execute Python with -c or write an intermediate script. Both can then modify sys.path and then load bar.py. Obviously this is not as nice as having a direct command-line switch or ._pth mechanism available.

I hope I explained enough. If not - don't hesitate to ask.