An important thing is that I’m not using pyenv-virtualenv by itself. I’m using it as plugin of pyenv. This explains the reason my terminal commands starts with pyenv. Now, going straight to the point that most attracted me:
1. Created virtualenvs are all at the same place
All virtualenvs that you create using the tool will be placed at the same directory: ~/.pyenv/versions. I’ve created three different environments so we can take a better look at that.
This is actually showing twice the same environments but if you add --skip-aliases (like the issue says) you’ll be fine:
A good benefit is that it avoids you from creating virtualenv directories arbitrarily on wherever you want and is prone to forget.
2. Pointing to python version when creating environment
Creating a virtualenv of a specific version of python is as easy as this: pyenv virtualenv <PYTHON-VERSION> <virtualenv-name>
3. Local python for project-specific needs
This is the one that I like the most. If you type pyenv versions, you get a list of python versions and virtualenvs available for use.
I’m currently working on a project that always use my venv343 virtualenv. Once I have all my virtualenvs in the same place, I can use pyenv local venv343 command that tells my terminal to automatically use venv343 while in the project directory:
Once set, every time I go to that directory, my terminal will be using venv343. Notice that when entering the directory I ran pyenv local <version> before, my terminal automatically goes into the desired virtualenv. When I leave the directory, the virtualenv is deactivated.
Way of work
The reason of adopting pyenv and pyenv-virtualenv is so that I can create a standard way of working with python projects that requires little intervention of myself. I transfer to these tools the responsabilities of things like enabling or disabling virtualenvs or using the correct python version executable. Let me know you that makes sense to you and also how you usually do it, which tools you use. : )