Short answer is - pyvenv does support core venv, only as a fallback and only as of Sept 2019.
More details as of Apr 2020:
- Very basic support is afforded by the emacs
python
module. This is generic enough to work with both virtualenv and venv. See convenience function python-shell-virtualenv-root
. This will set the virtual environment, but there are no tools to create, workon, delete environments. Ref: https://elpa.gnu.org/packages/python.html
pyvenv
has support in github as of Sept 2019. Looking at the source it defaults to virtualenv and python, rather than python3 - and this doesn't look to be configurable - so virtualenv must not be on the PATH and python3 must be set interactively to use venv otherwise it will default to calling python(2) on most setups. Still this is perfectly usable. See commit here https://github.com/jorgenschaefer/pyvenv/commit/392e28dad42dc6cc9507e496391a32482f9f1881
virtualenvwrapper
doesn't support and seemingly cannot be spoofed into using venv. There is a setting to set the name of the executable but it doesn't allow for setting of parameters. If you create a wrapper script or alias, this doesn't work on Debian based system at least, due to lack of support for ensurepip. I've raised a ticket here, but the wider underlying problem is with Debian not the emacs package: https://github.com/porterjamesj/virtualenvwrapper.el/issues/78
anaconda-mode
has basic support from the underlying pythonic
package. It's basically a wrapper on the core emacs support so should work fine with venv. The wrapper seems to handle TRAMP references to venvs for working with remote virtual environments as well as local ones. I haven't tested this - see https://github.com/pythonic-emacs/anaconda-mode#virtual-environment
There are various other projects on github, none of which looked actively maintained and all supporting virtualenv only.
For completeness the package bundle elpy
, uses pyvenv
, so should inherit support too - see https://elpy.readthedocs.io/en/latest/concepts.html#virtual-envs