Exec py_test targets in a way that would work with --run_under=lldb

[keith]

🚀 feature request

Description

When you're debugging python targets that load python C extensions, it can be useful in general to run something like lldb -- python3 -m pytest path/to/tests. In bazel I would envision this as bazel test --run_under=lldb :tests, but this doesn't work currently since py_test execs a script with a shebang. I think in theory if py_test ran the equivalent of python3 path/to/script it could "just work" but I'm not sure.

Describe alternatives you've considered

You can try to catch the process by launching the debugger elsewhere like lldb --wait-for -n python3.11, but this is a bit fragile since you could catch the wrong process

[aignas]

idea 1 - running the command lldb -- python3 -m pytest path/to/tests

A few thoughts, since we need the $(PYTHON3) interpreter reference in most of the commands here and we may also need to execute pytest as part of the command line, it does feel like passing --run_under may be insufficient. The tools that we pass may need to be accessed via labels and I am wondering if the approach described here can be extended to also change the actual entry point that is executed for the tests.

lldb could be a common enough scenario that could be enabled via a build configuration change.

idea 2 - running lldb <script>

The script bootstrap, that makes the py_test target execute the following scripts:

1. Bash script that detects the runfiles and launches a python script from there
2. Python script that setups the sys.path.
3. The python script that is the pytest entrypoint or the unit test file containing the tests and the unittest.main() execution.

I think using this new feature should make the lldb just work. @keith, have you tried running bazel test --run_under_lldb --@rules_python//python/config_settings:bootstrap_impl=script :tests?

[keith]

have you tried running bazel test --run_under_lldb --@rules_python//python/config_settings:bootstrap_impl=script :tests

I hadn't but it looks like that doesn't work. AFAICT the script produced in this case ends up being the bash script you mentioned in 1, which also isn't a valid lldb target. I think for it to work it would have to be directly python3 being run, even if the first part of that run was setting things up and running something else.

Like I wonder if instead of running the shebang script if we literally just ran that with the py3 executable it would work instead

[aignas]

I guess you would have to change this line to somehow inject lldb in order for this to work.

The annoying thing is that for the python interpreter to work, we need to run some shell or C program and then the debugger needs to be somehow passed as a parameter to rules_python, but that may not provide users with the ability to just use bazel's --run_under my_debugger, which is unfortunate.

[keith]

maybe a cool way to make this work could be to use something like --run_under=@rules_python//some:label which acted as an abstraction for setting whatever internal env vars or something necessary to do this. I guess that might not be flexible enough to support the multiple things people might want like gdb/lldb/strace etc

[rickeylev]

Does using --run_under set anything in the environment we can detect in the shell script?

[keith]

I'm thinking maybe the label we set would just be a shell / py script that did an export and exec'd the args

[UebelAndre]

Does using --run_under set anything in the environment we can detect in the shell script?

I don't believe it does. Some time ago I had attempted to do bazelbuild/bazel#16540 but never got a review. It would be awesome to empower rule authors to plumb --run_under through process wrappers so if something like that happens here I'd be very interested to know about it 😄