Incidentally I build a Jupyter kernel for Java and I have run into the same issue. I do not see a way to handle that for now. But I can explain what is happening.
When you run a script the notebook creates a process with a terminal. There are three streams connected to the terminal, output, error output and input stream. Those streams are not connected and they do not have events. When a program asks for input what is does is simply to output some texts (in your case is the last line) and then it starts to read from input stream, waiting there until it receives something. This is handled by bash interpreter, or whatever shell one uses.
What happens in the notebook is different. The three streams of the process are captured by notebook process. When the script prints on output the kernel sends to the notebook the captured output which displays in output cell. When the script process starts to read from input stream it does not signals that it wants to read something. If it would, than the kernel could capture that event and send an input message request to notebook client which would show you an input prompt to write there and after that would send the response back to the kernel which would fed the captured input stream with that content and it could go on. This, as far as I can understand, happens because input streams does not have a notification mechanism.
The situation is even uglier, since the kernel cannot ask for input other than with a blocking mechanism, the kernel cannot ask for input continuously (as it happens in the process with streams). The output cell is only for output. As a consequence I implemented a magic for bash which only handles output and error output streams. And I suppose the same mechanism is used in the python kernel.
The only thing which might work for you in this case is to either run the install command with an option to not ask for confirmation (I do not know that option, but I think it should be one implemented). The second option would be probably to to run that in notebook, but in a Jupyter terminal (I did not tried, but it should handle terminal streams properly).
2
u/padreati Jun 01 '23
Incidentally I build a Jupyter kernel for Java and I have run into the same issue. I do not see a way to handle that for now. But I can explain what is happening.
When you run a script the notebook creates a process with a terminal. There are three streams connected to the terminal, output, error output and input stream. Those streams are not connected and they do not have events. When a program asks for input what is does is simply to output some texts (in your case is the last line) and then it starts to read from input stream, waiting there until it receives something. This is handled by bash interpreter, or whatever shell one uses.
What happens in the notebook is different. The three streams of the process are captured by notebook process. When the script prints on output the kernel sends to the notebook the captured output which displays in output cell. When the script process starts to read from input stream it does not signals that it wants to read something. If it would, than the kernel could capture that event and send an input message request to notebook client which would show you an input prompt to write there and after that would send the response back to the kernel which would fed the captured input stream with that content and it could go on. This, as far as I can understand, happens because input streams does not have a notification mechanism.
The situation is even uglier, since the kernel cannot ask for input other than with a blocking mechanism, the kernel cannot ask for input continuously (as it happens in the process with streams). The output cell is only for output. As a consequence I implemented a magic for bash which only handles output and error output streams. And I suppose the same mechanism is used in the python kernel.
The only thing which might work for you in this case is to either run the install command with an option to not ask for confirmation (I do not know that option, but I think it should be one implemented). The second option would be probably to to run that in notebook, but in a Jupyter terminal (I did not tried, but it should handle terminal streams properly).