-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which env should be first when there's two? #1247
Labels
Comments
I think we have issues from a while ago about people being surprised that if they run |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Proposed change
When running with an older Python (just 2.7 prior to #1239, <= 3.6 and more in the future), there are two environments:
These two variables are both always defined, so absolute paths with env variables can always be used to disambiguate. In most cases, these two are the same, but in the too-old-python cases, they will differ. The question is: which should be first, and when?
There's ambiguity on the command-line, because both envs are on $PATH. Right now, we are in a bit of a peculiar situation, because $NB is first on path so that e.g.
jupyter-lab
will launch in the server env, but we set CONDA_DEFAULT_ENV so thatconda install
installs in the kernel env -it is assumed that runtime installation will want to go in the kernel environment. However, this means thaconda install
andpip install
will install to different environments, andpython script.py
,ipython
, etc. will launch in the server env, not the kernel one. (aside:%pip install
from a notebook will work, because that reliably resolves to the kernel's env, regardless of $PATH).I think in most cases, when the two differ the least surprise will occur if $KERNEL_PYTHON_PREFIX comes first. This is easy enough to switch, but we need to be careful to ensure that the launch command finds the NB prefix first, even if the rest of the time the KERNEL prefix should come first. Anything that relied on the server env being first may also break. This should only come up, though, for commands that are present in both prefixes -
python
,pip
,jupyter
, etc. It's not a pure win, though - common postBuild commands operate on the server env, likejupyter labextension install
. Some of these could break if we switch.Whether we change it or not, I think we should surface these environment variables, and encourage folks to use them when running commands to be explicit about which env they are running in, especially in postBuild.
Alternative options
conda install
Who would use this feature?
Users who execute
jupyter
orpython
orpip
commands in the terminal, either at runtime in the container (e.g. in a terminal), or in steps likepostBuild
.One of the more common
postBuild
steps is something likejupyter labextension install
. This relies on the current $NB prefix being first. It will actually work most of the time in both cases, as long as jupyterlab is not also in the kernel env (jupyter [subcommand]
works across envs if both are on your path - it just picks the first it finds).How much effort will adding it take?
It may be tricky to get the details right in keeping our default launch command working, if we switch the kernel to be in the front, since there are a lot of cases:
jupyter-lab
(which should be in the front here?)jupyter-notebook
Who can do this work?
Folks with path/shell environment and possibly conda env activation experience
The text was updated successfully, but these errors were encountered: