spacemacs
spacemacs copied to clipboard
Python mode hook for pyenv-mode can overwrite Python interpreter set by virtualenv
Description :octocat:
Suppose you have a Python project that
- has a .python-version file (which specifies which Python interpreter should be used) and
- has a virtualenv. If you open a Python file after you have activated the virtualenv, and then start a Python REPL, the Python REPL will use the Python interpreted specified by file .python-version and not the one specified by virtualenv.
This is caused by the fact that the Python mode hook pyenv-mode-set-local-version will overwrite a Python interpreter that is set by pyvenv-activate (and which is stored in variable python-shell-virtualenv-root).
Reproduction guide :beetle:
- Start Emacs
- Open a Python file in a project(ile) that has a .python-version file
- Activate a virtualenv using pyvenv-activate
- Open a new Python file in the same project
- Open a REPL using python-start-or-switch-repl
Observed behaviour: :eyes: :broken_heart: The REPL uses the Python version specified in the .python-version file, not the one specified by the virtualenv.
Expected behaviour: :heart: :smile: The REPL uses the Python interpreter specified by the active virtualenv.
System Info :computer:
- OS: gnu/linux
- Emacs: 26.3
- Spacemacs: 0.300.0
- Spacemacs branch: develop (rev. 2bc80b4b4)
- Graphic display: t
- Distribution: spacemacs
- Editing style: vim
- Completion: helm
- Layers:
(yaml auto-completion c-c++
(c-c++ :variables c-c++-backend 'lsp-ccls)
emacs-lisp javascript git gtags helm html journal lsp lua markdown org
(python :variables python-backend 'anaconda python-formatter 'black python-format-on-save t python-test-runner 'pytest)
(shell :variables shell-default-height 30 shell-default-position 'bottom)
syntax-checking treemacs)
- System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS
Backtrace :paw_prints:
The issue does not result in a backtrace.
As mentioned, the hook pyenv-mode-set-local-version overwrites python-shell-virtualenv-root, which is set by pyvenv-activate. IMHO (but I can be wrong) the interpreter of the active virtualenv should have precedence over the one that is specified in a .python-version file. If that is indeed the case, pyenv-mode-set-local-version should do nothing if pyvenv-activate is not nil. If you agree, I can make a pull request for this.
There is a workaround: just (re)activate the virtualenv in the file that you just opened. However, fixing this would be better :)
EDIT: in hindsight this is a bad workaround as python-shell-virtualenv-root
is reset every time you open a new file from the same project.
Can it be solved with the pyenv plugin https://github.com/pyenv/pyenv-virtualenv ? https://github.com/pythonic-emacs/pyenv-mode/issues/10 As i understand, it addresses the issue of management of both, pyenv and virtualenv.
It might be solved by using pyenv-virtualenv en pyenv-mode, especially if you use pyenv-virtuelenv to manage your virtualenvs :). However, I use tox to manage my virtualenvs, which is also a valid workflow.
IMO the underlying question is whether pyenv-mode should override the virtualenv settings by pyvenv, that is, the value of variable python-shell-virtualenv-root
.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!