elpy
elpy copied to clipboard
jorgenschaefer
Elpy is not using my Python from my virtual environment
I want to use the python installed on my virtual environment (using conda) which I have set up following this post: Using conda environments in emacs
But when I start emacs Elpy does not load the Python interpreter in this environment, nor jedi, autopep8... installed also there.
Ely Configuration
Virtualenv........: science (/Users/pablo/science)
RPC Python........: 2.7.10 (/usr/bin/python)
Interactive Python: python (/usr/bin/python)
Emacs.............: 25.1.1
Elpy..............: 1.12.0
Jedi..............: Not found (0.9.0 available)
Rope..............: Not found (0.10.3 available)
Importmagic.......: Not found (0.1.7 available)
Autopep8..........: Not found (1.2.4 available)
Yapf..............: Not found (0.12.1 available)
Syntax checker....: Not found (flake8)
Hi @ChillarAnand, I am doing this using this line in my Emacs config:
(pyvenv-activate "science")
And Elpy loads the environment:
Ely Configuration
Virtualenv........: science (/Users/pablo/science)
...
But not the Python interpreter in it, nor the other packages:
...
RPC Python........: 2.7.10 (/usr/bin/python)
Interactive Python: python (/usr/bin/python)
...
Jedi..............: Not found (0.9.0 available)
Rope..............: Not found (0.10.3 available)
Importmagic.......: Not found (0.1.7 available)
Autopep8..........: Not found (1.2.4 available)
...
Hello, and thanks for the report. I do not know or use conda – is /Users/pablo/science an actual virtualenv? I.e. can you activate it outside of Emacs using source /Users/pablo/science/bin/activate?
Indeed, it is not. I am using this config tu access the environment but it does not work right.
(setenv "WORKON_HOME" "/Users/pablo/miniconda3/envs")
(pyvenv-mode 1)
(pyvenv-activate "science")
/Users/pablo/miniconda3/envs should be the place where look for the environments.
I experience the exact same problem (OS X 10.11.6 + homebrew). Elpy-config acknowledges that the virtual environment is active, but it still uses the binaries from /usr/local and the modules I have installed in the environment are not found. It is also the case even if I start Emacs from a terminal where I've used "workon" to set the environment, and in that the PATH variable contains has the environment bin directory first. Curiously, it finds flake8.
Virtualenv........: Emacs (/Users/mok/.virtualenvs/Emacs)
RPC Python........: 3.5.2 (/usr/local/bin/python3)
Interactive Python: python3 (/usr/local/bin/python3)
Emacs.............: 24.5.1
Elpy..............: 1.12.0
Jedi..............: Not found (0.9.0 available)
Rope..............: Not found (0.10.3 available)
Importmagic.......: Not found (0.1.7 available)
Autopep8..........: Not found (1.2.4 available)
Yapf..............: Not found (0.12.2 available)
Syntax checker....: flake8 (/Users/mok/.virtualenvs/Emacs/bin/flake8)
This is the PATH:
(Emacs) homunculus➜ ~ echo $PATH
/Users/mok/.virtualenvs/Emacs/bin:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/var/rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/mok/bin
RPC Python........: 3.5.2 (/usr/local/bin/python3)
Did you set elpy-rpc-python-command to "python3"? Does it work if you use the default, "python"?
Yes, during Emacs initialization I set:
(setq elpy-rpc-python-command "python3")
I doubt it will work with "python", because I don't use Python2 and it's not configured for virtualenv.
I doubt it will work with "python"
Inside a virtualenv, the interpreter is always called python.
Ah, didn't realize that. Very confusing. Anyway, I tried changing elpy-rpc-python-command to "python" as you suggest and I get Python2 as expected. (I'm not sure where the interactive one comes from).
Virtualenv........: Emacs (/Users/mok/.virtualenvs/Emacs)
RPC Python........: 2.7.12 (/usr/local/bin/python)
Interactive Python: python3 (/usr/local/bin/python3)
Emacs.............: 24.5.1
Elpy..............: 1.12.0
The remaining lines are identical to the ones I reported above.
I also notice that when I do M-x elpy-mode I get the "Emacs" virtenv in the mode-line, but I if do M-! echo $PATH I do not have the virtenv bindir on the PATH. I should perhaps also say that I'm using zsh as my default shell.
Oh, I said something wrong, ~/.virtualenvs/Emacs/bin is on the path when I do M-! echo $PATH, only it's in the middle somewhere, after /usr/local/bin etc.
I activate the virtenv when the package is loaded (using use-package) like this:
(pyvenv-workon "Emacs")
Yes, exec-path-from-shell is installed, but I didn't do it manually?! It must have come in from melpa as a dependency somehow? I will try to remove it and see what happens.
I am now convinced it has something to do with the PATH. I examined the PATH I get in Emacs (using M-! echo $PATH) and my normal zshpath. In Emacs, the following are added at the beginning (it seems twice):
/usr/local/opt/coreutils/libexec/gnubin:
/usr/local/bin:
/usr/local/opt/coreutils/libexec/gnubin:
/usr/local/bin:
~/.virtualenvs/Emacs/bin:
These are both added explicitly in my .zshenv because I want to use GNU's coreutils and home-brew's binaries to take preference over the stuff in /usr/bin that Apple provides, and I want that in both scripts and terminal sessions.
When I invoke workon Emacs from the terminal, I get
~/.virtualenvs/Emacs/bin:/usr/local/opt/coreutils/libexec/gnubin: ... etc.
so the virtual environment works as it should. Inside Emacs, however, it seems my .zshenv is sourced twice after the virtenv has been set up. Perhaps it would be a good idea if elpy took charge of putting the virtenv path first? Your users must have a 1000 different ways of setting up the path variable, each one different.
Thank you for your time and effort!
Perhaps it would be a good idea if elpy took charge of putting the virtenv path first?
Elpy (or rather, pyvenv.el) does, actually. Sadly, this being Emacs, there are tons of hooks and packages that run after Elpy and pyvenv had their go. In a highly customizable environment like Emacs, you can't protect users from themselves.
(Removing exec-path-from-shell doesn't change the behaviour I described above.)
I have a suspicion that the problem is a combination of how pyvenv runs post-activation hooks and your zshrc … Could you set shell-file-name to /bin/bash or something and see if that fixes the problem?
What I was thinking was allowing the user to specify the path for Python, for example:
(setq elpy-rpc-python-command "~/.virtualenvs/Emacs/bin/python3")
I know it defeats the purpose of pyvenv but given what you say above it seems difficult to ensure that it works. Given the correct version of Python, the PYTHONPATH to the underlying Python packages would be given as well.
My idea for this setup was to isolate all the Python packages needed by elpy in a virtual environment "Emacs". I guess I have to give up on that idea and just install everything in my normal non-virtual environment.
What I was thinking was allowing the user to specify the path for Python, for example
That code you gave should already work, actually.
Wow you are fast 😀 I will poke around and try out your latest 2 suggestions, using bash and pointing to the precise Python binary.
Using bash as the shell inside Emacs seems to solve my problem. I hope the discussion above can also help @PabloRdrRbl ! If I set:
(setq shell-file-name "/bin/bash")
I have the virtualenv bin directory first on the PATH, and I get the following output from elpy-config, which seems completely correct!
Virtualenv........: Emacs (/Users/mok/.virtualenvs/Emacs)
RPC Python........: 3.5.2 (/Users/mok/.virtualenvs/Emacs/bin/python3)
Interactive Python: python3 (/Users/mok/.virtualenvs/Emacs/bin/python3)
Emacs.............: 24.5.1
Elpy..............: 1.12.0
Jedi..............: 0.9.0
Rope..............: 0.10.3
Importmagic.......: 0.1.7
Autopep8..........: 1.2.4
Yapf..............: 0.12.2
Syntax checker....: flake8 (/Users/mok/.virtualenvs/Emacs/bin/flake8)
Thanks again for you time & effort helping me get this setup right! 👍
I experience the same (?) problem using elpy 1.17. In a venv setup, I installed python3 (python --version indicates 3.6.3). I manage to activate this venv in elpy, but unfortunately both rpc and interactive python are v2.
Virtualenv........: jedi3 (/home/pascal/.emacs.d/virtual-venvs/jedi3)
RPC Python........: 2.7.14 (/usr/bin/python)
Interactive Python: python (/usr/bin/python)
Emacs.............: 25.2.2
Elpy..............: 1.17.0
Jedi..............: 0.10.2 (0.11.0 available)
Rope..............: Not found (0.10.7 available)
Importmagic.......: Not found (0.1.7 available)
Autopep8..........: 0.9.1 (1.3.3 available)
Yapf..............: 0.15.1 (0.20.0 available)
Syntax checker....: flake8 (/usr/bin/flake8)
Setting the shell to bash does not change the result I get.
I noticed this too. Elpy does use the venv correctly to start interactive Python shells, but RPC python does not use the interpreter of the venv (which may also be difficult since we could have shells open with different venvs).
Here is my output (for current venv py35):
Virtualenv........: py35 (c:/Users/rg/AppData/Local/conda/conda/envs/py35)
RPC Python........: 3.6.1 (c:/Users/rg/Anaconda3/python.exe)
Interactive Python: jupyter (c:/Users/rg/AppData/Local/conda/conda/envs/py35/Scripts/jupyter.exe)
I guess the solution is to set elpy-rpc-python-command to the respective binary in the venv.
Elpy really should find the correct python interpreter if it's available inside your virtualenv. The question only is whether M-: (executable-find "python") finds the correct executable, and if not, why not.
It doesn't. pyvenv-workon seems to only add the Scripts subdirectory to exec-path (which is where ipython and jupyter is), but not the main directory (which is where python is).
For me after activating py35:
exec-path is a variable defined in ‘C source code’.
Its value is
("C:/Users/rg/AppData/Local/conda/conda/envs/py35/Scripts"
"C:/Users/rg/AppData/Local/conda/conda" ... )
C:/Users/rg/AppData/Local/conda/conda/envs/py35 is missing.
… why is the python.exe not in the scripts folder? Windows can't really stick to any standard, can it? :angry:
In a system shell, the correct paths are added to the PATH environment variable, which is why it works there.
Well, in my case it's not technically Windows but Anaconda. Not sure how Anaconda does it on Linux.
Anyway, @pascal-niklaus, it may help to check if exec-path does contain the path to the venv's executables.
I'm majorly confused by this. Does this mean emacs-pyvenv needs to add the virtualenv root directory to exec-path to work correctly on Windows? That's very strange?