Isomorphic IInstaller: Support installing dependencies with the debugger

[sadasant]

With PR: #10604 we realized that to have an isomorphic dependency installer we will need to use the debugger.

We have a dependency installer that has a nicer user experience, which is the IInstaller. If we were to implement an isomorphic installer, we would both use the debugger and IInstaller.

An important point to consider is that the code below does not work with the debugger:

// TODO: Installing pandas does not work with the debugger.
// It takes a long time, then it breaks with:
// error: Command \"clang -Wno-unused-result -Wsign-compare -Wunreachable-code...
export const debuggerInstallPandas = [
    'import subprocess as _VSCODE_subprocess',
    'import sys as _VSCODE_sys',
    `def _VSCODE_install_pandas():
  _VSCODE_subprocess.check_call([_VSCODE_sys.executable, "-m", "pip", "install", "pandas"])`,
    '_VSCODE_install_pandas()',
    'del _VSCODE_subprocess, _VSCODE_sys, _VSCODE_install_pandas'
];

To correctly implement the isomorphic installer, we might need to study how %pip and %conda are implemented on Jupyter.

[DonJayamanne]

we might need to study how %pip and %conda are implemented on Jupyter.

I think we can avoid reverse engineering anything here.
Instead we could

• When debugging we can use the debugger to get the path to the python executable & then run the necessary code against the python executable
  • This is what we do today, indirectly, we know the python environment & we run the commands against that.
• Use IKernel to install the necessary modules (as is done today) for both local & remove kernels

Basically I think we can make this work easily today with very little changes.
In debuger we can run import sys; sys.executable using that we can get the interpreter information today & run the installer against the python environment as we do today.

[rchiodo]

In debuger we can run import sys; sys.executable using that we can get the interpreter information today & run the installer against the python environment as we do today.

Not sure how this would work in remote or web.

[DonJayamanne]

Not sure how this would work in remote or web.

In that case we have the kernel, and we can use the kernel.

[rchiodo]

In that case we have the kernel, and we can use the kernel.

Not while debugging. Still need to eval something. Hence the idea to figure out what %conda or %pip do, as that's what we'd eval.

[DonJayamanne]

Not while debugging. Still need to eval something.

When debugging the only time we don't know IKernel is when the user laucnhes the debugger, and that point we can call sys.executable.
This will not work only in remote debugging, which is only possible with IW & NB, however at that point we have an IKernel.

Hence we always have an IKernel except in local cases when user starts a debug session for python files using python extension.
If Python implements remote debuggin in web, then we can easily display a message asking the user to manually install pandas manually, as I believe that's a very small user base (we can determine this from the telemetry) & avoids the need to reverse engineer any of the code used in %conda & %pip, making the solution a whole lot simpler.

Perhaps we can discuss in standup.

[rchiodo]

Even with an IKernel, if you're debugging a cell or debugging the IW, you can't use the kernel to do the install. It's frozen. So you need to eval some code from the debugger.

Maybe we just skip installing when debugging then. Although I think the install magics wouldn't be very hard to call:
https://github.com/ipython/ipython/blob/0f4a73c91db71cde174275337fc5e226acc9dd7d/IPython/core/magics/packaging.py

[DonJayamanne]

It's frozen. So you need to eval some code from the debugger.

Aah yes, you're right, forgot about that one (thought that only applies to debugging remote kernels, but not a consistent experience if we don't support remote).

[sadasant]

Closing on favor of: #10638