Interpreter selection is challenging

[astrojuanlu]

I just installed JupyterLab Desktop for the first time after reading https://blog.jupyter.org/introducing-the-new-jupyterlab-desktop-bca1982bdb23, and found the interpreter selection (necessary step before doing anything else) a bit challenging. Here's a timeline of what I did:

1. Upon opening the app for the first time, I see a warning "⚠️ Python environment not found". Which makes a lot of sense 👍🏽 I do have existing micromamba environments though, so I'll try to configure one of those. I don't want to use the bundled installer.
2. I pick the path of the interpreter of my desired environment. "Apply & restart" still tells me "⚠️ Python environment not found". Which is okay-ish 😐 because I understand that a barebones installation is probably not enough, but at the same time the error message is a bit misleading. In fact, I double-checked the path just to make sure I copy-pasted it correctly.
3. I pip install ipykernel inside that environment, and I still get "⚠️ Python environment not found". Now this is getting a bit annoying 😕 because VS Code just requires ipykernel, and from my limited understanding of the Jupyter architecture, I thought this is the only piece that an existing Jupyter client needed to use an interpreter.
4. I reluctanctly pip install jupyterlab, and now I don't see "Python environment not found" anymore. Progress! 👍🏽 but I'm prompted with another warning "⚠️ Select conda base environment" dialog 🤔 if I cancel, I'm back to the welcome screen with all options available, but it's misleading because if I click "New notebook...", I get the base environment selection again.
5. Despite the minor fact that I don't use conda, but (micro)mamba, I proceed to select the "conda root" with the dialog - which I guess needs to be a directory, since micromamba env list tells me that base is in /Users/juan_cano/.micromamba. I pick that directory, and I land on a screen that says "Failed to create session! Invalid base conda environment" 😓 micromamba environments not supported #596
6. I'm left thinking whether the app is searching for a conda executable (which it won't find) or whether I typed the wrong path again. So I quit the app, open it, pick the "conda root" again... and it takes me to the welcome screen 😳 Clicking "New notebook..." after that prompts me once more to choose the "conda root", which now takes me to the "Invalid base conda environment" screen I expected. This one looks like a bug to me.

Context

• Operating System and version: macOS Ventura
• JupyterLab-Desktop version: 3.6.1-2
• Installer: .dmg

Browser Output (required for interface issues after loading)

Two more issues:

• There is not "Help" menu.
• There is a "View" -> "Toggle Developer Tools" entry, but clicking on it does nothing.

Logs (required for issues with loading, server and startup)

Couldn't find how to launch the app from the CLI:

• jlab was not found (maybe not in the $PATH)
• '/Applications/JupyterLab.app/Contents/Resources/app/jlab' exists but is not an executable file.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[krassowski]

just requires ipykernel, and from my limited understanding of the Jupyter architecture, I thought this is the only piece that an existing Jupyter client needed to use an interpreter.

👍 I have written a bit more in-depth explanation on why it the way it is: #473 (comment) and why I do not like it but your argument is valuable as it concisely shows how user expectations are broken.

[mbektas]

@astrojuanlu desktop app was not tested for micromamba but mainly with conda and venv. we will investigate the issues you reported.

[astrojuanlu]

Btw I found why I was not able to launch jlab from the CLI:

juan_cano@M-PH9T4K3P3C ~> /Applications/JupyterLab.app/Contents/MacOS/JupyterLab
ln: /usr/local/bin/jlab: Permission denied

Will open a separate issue for micromamba support.

[michaelaye]

I have to agree. Many years user of conda and "terminal"-jlab user here. I simply don't understand what jlab-desktop wants from me? No path I tried worked. What IS the path to a conda base/root ? I tried the very general $HOME/mambaforge but I also tried $HOME/mambaforge/bin/python and $HOME/mambaforge/envs/py311/bin/python (which has ipykernel installed). Nothing was accepted. Note that there isn't anything special about mambaforge, it just defaults to a different channel and uses the mamba execetuable on top of fully existing conda exectuable so nothing should interfere with jlab-desktop.

[krassowski]

@michaelaye when you tried various environments did they have the latest JupyterLab version installed or not? Just looking at your comment, other issues and documentation it seems that maybe this quite important requirement is no longer exposed as it should be.

[mbektas]

@michaelaye JupyterLab Desktop doesn't support mamba environments yet. They might be detected as conda environments by the app, but if you don't have conda installed, then env activation would fail.

[michaelaye]

To my knowledge, the usual mamba (so, not micromamba) doesn't actually work without conda installed, so there should actually be no difference between an environment created by conda or mamba?

[krassowski]

It seems my question was missed, but this (missing jupyterlab installation) was the reason in #704 where I commented that the information about missing JupyterLab information does not seem to be exposed in UI when environment startup fails.

[michaelaye]

Ah sorry, about having the most recent jupyterlab: Yes, when I try to point it to my “work envs”, they are always up to date and “fully equipped”, No, for the base env, as a full install of a science stack is “frowned upon” for the base env, as that env is also used for managing conda itself. But, as I said, it is also unclear from the UX if I have to point it to the base env or if any fully equipped env should work. And to which precise path? I was inferring from the existing setting, that I need to point to the Python executable in all cases, is that correct? I admit, I didnt read the docs…

[michaelaye]

According to the docs, pointing to /Users/klay6683/miniforge3/envs/py311/bin/python should work, and it does work fine on my macOS. I will check again tomorrow on my Linux machine, if there's anything different in terms of my conda/mamba envs to my macOS envs.

[michaelaye]

Sorry for the delay. Here are some observations on my Linux system:

• first, a small dialog window asks me to pick a conda base
  • Small inconsistencies start there: Window title: "Select conda base environment", First sentence: "Base conda environment". These terms can have slightly different connotations, the app should pick one and stick with it.
• after clicking OK, a file explorer window (see screenshot) opens, which has a big blue button "Use Conda Root".
  • What is Root? The old term for Base? or do you mean something else here? It's also unclear at this point, if you REALLY want the conda base environment, or just any environment that has a complete jupyterlab install.
• I pick an env now that for sure has a working and complete install of jupyterlab
  • but, should I pick the env folder, or the bin folder in that env? Unclear..., I select <env_name>/bin.
• to no avail, not even after restarting app. Trying to open a "New Notebook" pops up again the request to choose conda base. This time I select the env folder itself, so "mambaforge/envs/py311". But then I get "Failed to create session!"
• Aha! But does that mean that the previous try kinda worked (no error!) but not really? (as it didn't open a new notebook based on the selected env?
• I am going back to trying the actual base env (even so, that has no ipython kernel, as that is not a recommended modus operandi), also to no avail.