Custom python environment support

[mbektas]

Adding basic support for custom Python environment installed on user machine

• Python environment info is shown on status bar
• conda and venv are both supported
  • Status bar item has the label as follows: conda: env_name (for conda), venv: env_name (for virtualenv), system: python (for other cases)
  • Hovering on status bar item shows env type and name, python path, python & jupyterlab versions
• Clicking status bar item launches the environment select dialog
• Setting is persisted as part of application state
• At launch time, compatibility of selected python path is checked (including bundled environment, since user can modify it) and if found incompatible, Python path selector dialog is shown with the incompatibility error message.

Status bar item

Changing environment

Failed launch due to incompatible environment

[krassowski]

I was thinking more renderToString style from react-dom (which already is a dependency), but I guess that would work too. I don't think yarn.lock was updated, how much does inclusion of ejs costs us in terms of extra dependencies?

[mbektas]

ejs was already included through another dependency. I will also check out react-dom renderToString you mentioned.

[mbektas]

@krassowski I looked into ReactDOMServer.renderToString. it doesn't look like an easy integration for our use case. we generate the HTML of the dialogs on the app backend using node.js. Dialog front-ends are quite basic HTML and JS. We would need to use react for dialog front-ends which would be significant overhead just for sanitize purposes. Also, sanitization would happen on the front-end which may not be as secure as intended.

Please let me know if I missed something and if you see an easier integration of ReactDOMServer.renderToString.

[bollwyvl]

Hm, it looks like my reply was swallowed by the aether (happens), here's a paraphrase:

Strictly from a conda perspective: if the canonical conda activate (or shell-appropriate analog) is not applied, the eventual environment will be inconsistent, creating weird problems.... known offenders include java/clojure, or anything that has a pre-activate script.

Some approaches:

• dynamically make a shell-appropriate (.sh or .bat) wrapper script that activates and then launches
  • gross, slow...
    • ...but works every time
• use conda run
  • clean, relatively fast
    • but doesn't work so well with mamba...
      • ...unless the "heavyweight" shell initialization is in place, which has its own problems
      • ...much less venv

At any rate, perhaps an appropriate play is to handle the two incumbent providers explicitly, implemented as the former, and then a Customize Template... which would allow someone to further tweak them, or replace entirely with e.g. nix, vagrant, some docker abomination, etc. (many of which conda would be sufficient to provision, a la as discussed jupyterlab-contrib/jupyterlab-contrib.github.io#23 (comment)

[mbektas]

At any rate, perhaps an appropriate play is to handle the two incumbent providers explicitly, implemented as the former, and then a Customize Template... which would allow someone to further tweak them, or replace entirely with e.g. nix, vagrant, some docker abomination, etc. (many of which conda would be sufficient to provision, a la as discussed jupyterlab-contrib/jupyterlab-contrib.github.io#23 (comment)

@bollwyvl thanks for bringing this up. conda run looks pretty nice but venv requires a separate solution too. We should go for creating launch scripts that take care of env activation and then launching jlab as you suggested. As far as I could see, our packages in the bundled environment don't have pre-activate/activate scripts and this case seems to be rare. So, I think we can implement launch script generation in another PR.

[krassowski]

LGTM, thank you!