Keyboard interrupts are intercepted by --build_python_zip bootstrap

[bubski]

Description of the bug:

When running a py_binary built with --build_python_zip, keyboard interrupts are handled by the bootstrap, not giving the wrapped program a chance to handle them in a custom way.

This also reveals another issue with the module space cleanup code not being executed when exceptions occur in the bootstrap, and the temporary directory not being deleted.
I believe it should be moved to a finally: block, so that clean-up happens in case any other exception occurs. But I suppose it is a separate issue. Feedback on this is appreciated.

For context, I noticed all of the above while working on a Python project that starts an http server, and listens for keyboard interrupts to gracefully shut down.

• The suggested change to resolve the SIGINT issue in:
  python: Ignore SIGINT while running wrapped program from zip #20256
• The suggested change to resolve not cleaning up the temporary directory when an exception occurs:
  python: Remove temporary module space created for zip-based binaries when exception happens #20257

Which category does this issue belong to?

Python Rules

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Given a //:foo py_binary with such an implementation:

import time

print("foo: Hello")
try:
  print("foo: Sleeping...")
  time.sleep(5)
except:
  print("foo: Exception caught")
  for x in range(3, -1, -1):
    time.sleep(1)
    print(f"foo: handling exception ({x}s)")
print("foo: Goodbye")

when building and running it with:

bazel build //:foo --build_python_zip && bazel-bin/foo

we see

foo: Hello
foo: Sleeping...

if CTRL+C is pressed at this moment, the program manages to print an extra:

^Cfoo: Exception caught

but is terminated right after that, without the opportunity to handle the interrupt on its end.

---

The issue does not occur when building without --build_python_zip

bazel build //:foo && bazel-bin/foo

if the same steps as above are repeated now, we get:

foo: Hello
foo: Sleeping...
^Cfoo: Exception caught
foo: handling exception (3s)
foo: handling exception (2s)
foo: handling exception (1s)
foo: handling exception (0s)
foo: Goodbye

with the expected 0 status code.

Which operating system are you running Bazel on?

macOS 14.1.1

What is the output of bazel info release?

release 6.4.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response