Binderhub: Terminal doesn't activate the Binder environment in JupyterLab

[choldgraf]

I'm sitting at a workshop at UW and we just realized that when you specify the environment for a repository in Binder, it isn't activated by default when starting a terminal in JupyterLab. Is this a bug? I'm not sure, but seems confusing to people.

[betatim]

Do you have a link to a repo that we can use to see this happen (and fix it)? This might be a bug in repo2docker instead of BinderHub.

[choldgraf]

We found it in this repository:

https://github.com/alan-turing-institute/CompEnv-Ex1

the instructions in the readme actually do a good job of highlighting this 🐛

I'm in the middle (literally) of giving this tutorial so I may stop responding after this :-)

[betatim]

Starting that repository (or any other one that has a Python version different from the default one in its environment.yml) you get this:

jovyan@jupyter-betatim-2dsdfg-2dljpwgy1b:~$ python
Python 3.7.3 | packaged by conda-forge | (default, Mar 27 2019, 23:01:00)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
jovyan@jupyter-betatim-2dsdfg-2dljpwgy1b:~$
jovyan@jupyter-betatim-2dsdfg-2dljpwgy1b:~$ echo $PATH
/srv/conda/envs/notebook/bin:/srv/conda/envs/kernel/bin:/srv/conda/condabin:/home/jovyan/.local/bin:/home/jovyan/.local/bin:/srv/conda/envs/notebook/bin:/srv/conda/envs/kernel/bin:/srv/conda/bin:/srv/npm/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
jovyan@jupyter-betatim-2dsdfg-2dljpwgy1b:~$ conda env list
# conda environments:
#
base                     /srv/conda
kernel                   /srv/conda/envs/kernel
notebook              *  /srv/conda/envs/notebook

This means that the notebook env is active and the kernel env is on the PATH but the notebook one comes first. The end result is what Chris reported.

[choldgraf]

I guess the main thing to decide here is: is this a bug, or is it expected behavior? I'm not really sure, and I think that @kirstiejane assumed it was just expected. What do other folks think?

[betatim]

I think it is expected/as intended by the code in repo2docker. However I don't know why we made it so -> Should we change it?

It is for sure confusing that python in a terminal doesn't get you the Python interpreter in the version you asked for. A reason to change it.

[KirstieJane]

Light vote from me to change it....even if that means we'll have to fix our clever demo 😉

(Developed and figured out by @sgibson91 btw!)

[sgibson91]

Hey! We developed that example before the introduction of the separate notebook environment, so this has persisted for a while. I think I even had a conversation with @minrk about why I wasn't getting the Python version I expected in the terminal. At the time, I did think it was strange that you wouldn't get the Python version you asked for in the terminal, but typing source activate kernel wasn't such a huge imposition that I felt I should report it as a bug. But this should probably be changed for consistency, as you don't need to specify the environment for the notebooks so why is the terminal special? (Hypothetical q!)