Don't try to detect virtualenvs when starting a kernel #96
Conversation
I think automatically adding an active virtualenv to sys.path makes less sense in a kernel than it does in terminal IPython (and I'm less certain than I was even for terminal IPython). If Jupyter is installed inside a virtualenv, it will still launch the default kernel in there too, but this would mean that you can no longer run e.g. 'jupyter console' with a virtualenv active and find packages from that virtualenv.
There's no point doing the virtualenv check in the frontend, and the extra warning message is confusing. ipython/ipykernel#96 is for discussion, this one should just be a bugfix.
|
Judging from my current workflow, I would prefer a detection of the virtualenv. It would not require me to install Jupyter in every virtualenv or I won't have to create a new kernel for every virtualenv. |
|
Since after-the-fact env activation will always be semi-broken, +1 to this. |
|
To expand on what Min means by 'semi-broken': virtualenvs are isolated by default, so when you're running Python inside a virtualenv, it doesn't look for imports in your system or user Our virtualenv detection can't emulate this, because IPython itself is running in a Python outside the virtualenv. We add the virtualenv's Rather than just removing the feature silently, perhaps we can provide some machinery or documentation to help people who liked this.
|
|
It also means that any packages that have been imported by IPython prior to detecting the venv may be the wrong versions, causing confusion. Installing the kernel into the env automatically would be pretty slick. |
Don't try to detect virtualenvs when starting a kernel
|
Do we think this is appropriate for a 4.x release? It is a change in behaviour. |
|
I think it is, since it seems to me like fixing a bug (virtualenvs messed up your kernel's sys.path). But we can be conservative and call it 5.0. But if we do call it 5.0, I don't think that changes the scope of this release, it just means that everything currently marked for 5.0 becomes 6.0. |
|
Alternately, we can branch 4.x prior to this merge (or revert it) and continue discussing before to a later 5.0. |
|
I don't have a strong feeling, but given that some people are using this behaviour currently, the change should be in a major release. It would also be nice to have something to point those users to when they find it's gone. I think that points to branching 4.x before this merge. |
|
Very interesting discussion. FWIW, I didn't realize that this was the behavior happening when running in a virtualenv. My workflow is typically to create a virtualenv for each project and then install all needed into the virtualenv.
This explains some of the technical issues re: installation folks have had.
It would. However, it would nice to explicitly tell the user when automatically loading something new. |
|
Ran into this today. Updating to 5.0 broke my setup, since I installed jupyter globally and use it inside virtualenvs, so I would not have to install ipykernel inside every venv nor would I have to create a kernel for each.
Do you mean putting the old code inside e.g. |
|
You can use exec_lines, or a startup file. Sorry, but I don't think we're interested in maintaining the old behaviour as an option. |
I think automatically adding an active virtualenv to sys.path makes less sense in a kernel than it does in terminal IPython (and I'm less certain than I was even for terminal IPython).
If Jupyter is installed inside a virtualenv, it will still launch the default kernel in there too, but this would mean that you can no longer run e.g. 'jupyter console' with a virtualenv active and find packages from that virtualenv.