Provide a working configuration for windows and anaconda users

[galaunay]

The switch to a dedicated virtualenv for the RPC has made Elpy difficult to configure on windows, specially with anaconda (from user feedbacks and personal tests).

Preferably, we would need to make Elpy work out-of-the-box for windows and anaconda.
If not possible, the minimum is to provide working configuration examples.

[galaunay]

linked to #1729, #1728, #1727, and probably others.

[findesgh]

I'm having trouble with the switch to a dedicated virtualenv as well, though I'm running Elpy on Linux. Let me know if I should open a separate issue.

Summary

Elpy fails to create its own venv when Python is provided by a conda env and system Python is of different version.

Details

This happens on a compute cluster where I do not have root access. Since the Python provided by the admins is ancient, I use a conda env at ~/bin/miniconda3/envs/standard for everything, i.e. I activate this environment in my .bashrc but I do usually not activate it in Emacs.
Now to create its dedicated venv, Elpy tries to use ~/bin/miniconda3/envs/standard/bin/virtualenv with the interpreter at /usr/bin/python. Since /usr/bin/python is ancient Python 2 and I use Python 3 in my conda env, this does not work, of course.

My elisp is not the best, but as far as I understand, Elpy calls elpy-rpc--create-virtualenv and then tries to run virtualenv -p python ~/.emacs.d/elpy/rpc-venv wrapped into with-elpy-rpc-virtualenv-activated, which leads to it choosing /usr/bin/python as interpreter. I verified that otherwise it uses the Python from my conda env. I find it confusing that it tries to create the venv while it is activated. Is there a reason for this or am I misunderstanding something?

Workaround

A workaround was to conda deactivate and then temporarily remove /usr/bin from my $PATH and add ~/bin/miniconda3/envs/standard/bin to it. That allowed Elpy to do its thing and so far I've used it without problems.

Configuration

OS

Custom Linux

Elpy Configuration

Run after completing the workaround since it didn't work before that.

Emacs.............: 26.1
Elpy..............: 1.32.0
Virtualenv........: None
Interactive Python: ipython 7.4.0 (~/bin/miniconda3/envs/standard/bin/ipython)
RPC virtualenv....: rpc-venv (~/.emacs.d/elpy/rpc-venv)
 Python...........: python 3.7.3 (~/.emacs.d/elpy/rpc-venv/bin/python)
 Jedi.............: 0.15.2
 Rope.............: 0.14.0
 Autopep8.........: 1.4.4
 Yapf.............: 0.29.0
 Black............: 19.10b0
Syntax checker....: flake8 (~/bin/miniconda3/envs/standard/bin/flake8)

[galaunay]

I find it confusing that it tries to create the venv while it is activated. Is there a reason for this or am I misunderstanding something?

The trick is here:

(defun elpy-rpc--create-virtualenv (rpc-venv-path)
  "Create a virtualenv for the RPC in RPC-VENV-PATH."
  ;; venv cannot create a proper virtualenv from inside another virtualenv
  (let* ((elpy-rpc-virtualenv-path 'global)    ;;<==== HERE
         success
         (elpy-venv-buffname-visible "*elpy-virtualenv*")
         (elpy-venv-buffname (concat " " elpy-venv-buffname-visible)))
         ...

with-elpy-rpc-virtualenv-activated uses the value of elpy-rpc-virtualenv-path to activate either the RPC virtualenv, the current virtualenv or the "global" environment.
So let-binding it to global allows to use the "global" environment to create the RPC virtualenv.

The thing that is creating you problem is that Elpy determines which environment is the "global" one by getting the last python interpreter in PATH (in your case the old python2 one I presume). I admit that it is not optimal, but I couldn't find a better definition of what would be a "global" environment... Any idea is welcome on that matter.

A solution that could work in your case would be to create your own virtualenv for the RPC (let's say in ~/bin/miniconda3/envs/elpy-rpc) and specify its location in your configuration with (setq elpy-rpc-virtualenv-path "~/bin/miniconda3/envs/elpy-rpc").

[findesgh]

Ok, I see. I thought that there was something I'd missed :-).

Thanks for taking the time to explain, really appreciate that.