You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have python-shell-interpreter set to jupyter, and python-shell-interpreter-args to:
console --kernel python3 --simple-prompt
I have jupyter and a python3 kernel installed in several virtualenvs. Unfortunately, activating the virtualenv with pyvenv-workon myvenv runs the python3 kernel from the main environment (not myvenv).
This is what elpy-config shows with myvenv activated:
so it runs the right jupyter from myvenv, but presumably using the python3 kernel from the main environment as the sys.path shown is not from myvenv. Same thing occurs in a terminal outside Emacs.
I thought I could get around the problem by creating a kernel with the same as the virtualenv; i.e. create a kernel named myvenv in the example above. Then, use pyvenv-post-activate-hooks and pyvenv-post-deactivate-hooks to set python-shell-interpreter-args to call the appropriate kernel:
I have
python-shell-interpreter
set tojupyter
, andpython-shell-interpreter-args
to:console --kernel python3 --simple-prompt
I have jupyter and a python3 kernel installed in several virtualenvs. Unfortunately, activating the virtualenv with
pyvenv-workon myvenv
runs thepython3
kernel from the main environment (notmyvenv
).This is what
elpy-config
shows withmyvenv
activated:so it runs the right
jupyter
frommyvenv
, but presumably using thepython3
kernel from the main environment as thesys.path
shown is not frommyvenv
. Same thing occurs in a terminal outside Emacs.I thought I could get around the problem by creating a kernel with the same as the virtualenv; i.e. create a kernel named
myvenv
in the example above. Then, usepyvenv-post-activate-hooks
andpyvenv-post-deactivate-hooks
to setpython-shell-interpreter-args
to call the appropriate kernel:The post-activate hook works as expected, but not the post-deactivate hook, perhaps as per its docstring note: "‘`pyvenv-virtual-env’ is still set."
Any tips or alternative solutions?
The text was updated successfully, but these errors were encountered: