I just began to use pyenv to manage my python versions, and began to use the pyenv virtualenv plugin to manage my virtualenvs, and so far, I have loved it. One thing I miss
Short answer: You can’t, as far as I know.
It wouldn’t really work either, right? If you use pyenv virtualenv
to install a virtualenv into a repo, and you clone that repo to another machine… how would pyenv
on the new machine know to take control of the virtualenv in the repository?
Also, “you probably shouldn’t do that”. Virtualenvs are not 100% decoupled from the underlying Python installation, and aren’t really all that portable. And do you really want to litter your repositories with a bunch of easily replicated junk? The “right” way to go about things is probably to to maintain a requirements.txt
for pip — that way you can easily reproduce your development environment wherever you clone your repo.
That all said, there’s nothing stopping you from using plain old virtualenv
to create a virtualenv anywhere you like, even if you installed virtualenv
into a Python interpreter under pyenv
control. That virtualenv itself will of course not be administered by pyenv
, but you can still use it as you always did…
There's a workaround
In your project directory, create a .python-version
file. Assuming you already installed some virtual environment using pyenv-virtualenv
, then append this line to it(you may want to change the version number):
3.7.1/envs/your-project-name@3.7.1
Whenever you enter into the directory, the correct python version will be used, and it works pretty well.
Here is a GitHub issue on the project tracker asking about this: https://github.com/pyenv/pyenv/issues/802
The reply by a project collaborator was:
You can just create virtualenv in any location. To use it from pyenv, create symlink to the environment in ~/.pyenv/versions
although I must say I'm not very satisfied with this solution.