At this point the user is dumped back to the shell but the shell is not in a good state (hatch's child process python is in fact still running.)
Compare with just this, which could be the desired behaviour:
python
<Ctrl-C>
>>>
KeyboardInterrupt
>>>
(python also still running here, but it keeps control of the terminal)
In short: "hatch run" is not transparent because python inside hatch run does not behave the same way that plain python does. Letting the child process handle Ctrl-c as it wants to do will help multiple applications (another example: jupyterlab will ask the user to quit or not, with an interactive prompt, if you use Ctrl-c, and ipykernel will interrupt current computation but not quit, if you sent SIGINT.).
Inside a hatch project, try this:
The result is:
At this point the user is dumped back to the shell but the shell is not in a good state (hatch's child process python is in fact still running.)
Compare with just this, which could be the desired behaviour:
(python also still running here, but it keeps control of the terminal)
In short: "hatch run" is not transparent because python inside hatch run does not behave the same way that plain python does. Letting the child process handle Ctrl-c as it wants to do will help multiple applications (another example: jupyterlab will ask the user to quit or not, with an interactive prompt, if you use Ctrl-c, and ipykernel will interrupt current computation but not quit, if you sent SIGINT.).
Hatch, version 1.12.0 platform: linux (x86_64)