pyenv-virtualenv: .python-version doesn't refer to python version

The feature where cd’ing into a directory activates the virtual specified in .python-version seems the most confusing to me. Perhaps this feature could fallback to a .python-virtualenv file so that .python-version can contain the real python version? or maybe .python-version can contain both the version and the virtualenv?

this is a pain point for me as well, i ended up using the following format: .python-version:

3.6.3/envs/nameofmyenv

then in each project readme, i require the following to be run as a setup step, which is unfortunate:

# install the correct python version
pyenv install $(sed "s/\/envs.*//" .python-version)
# create a virtualenv
pyenv virtualenv $(sed "s/\/envs\// /" .python-version)

one idea is to extend pyenv virtualenv to with a command like pyenv install (without params) that reads this file/format and both ensures the right python version and the virtualenv exist, if not installs/creates them. would this work for anyone else?

This also got me today, coming from rbenv/nodenv I assumed .python-version would specify the python version and nothing else. Then a separate file, or just .venv folder would contain the actual virtualenv.

The ruby analogue would be rbenv+bundler, the first is solely for managing ruby version and the latter for application specific gems, aka pip, dependencies. Of course you can have a plugin for rbenv that integrates bundler, and here I thought this plugin would be the equivalent for pyenv.

For node it’s something similar, .node-version specifies the node version and npm* handles the dependencies, which are always installed locally into node_modules.

To be concrete, overloading .python-version is going to keep shooting people in the foot. But to avoid even more .<name>-version files, why not always keep the virtualenv in the same folder with some useful name? Then it can be easily git/hgignored and it would be obvious which virtualenv is which.

It would even allow easy detecting, just walk up the directory tree and look for a .venv folder.

*or any npm compatible tool, yarn/jspm/…

It does not really matter (for development) if you have 3.5 or 3.4 in the end.

It really does matter. People want reproducible builds so there is no chance of a newcomer running into unexpected issues.

Seems like the workaround for now is to specify the version in your virtualenv, as the Usage example:

$ pyenv virtualenv 2.7.10 my-virtual-env-2.7.10

New users can create a virtualenv of the same name.

For my projects, I will commit the .python-version file.

AFAIK, unlike RVM’s gemset, a virtualenv is tightly coupled with specific Python installation. Because of that, in pyenv-virtualenv, I implemented to manage a virtual environment as a version in pyenv. Splitting .python-version and .python-virtualenv will just introduce unnecessary complexity without benefit.

If it’s committed to source control then it makes things confusing…

Don’t commit it. Problem solved.

btw^2: pyenv works very well by itself without pyenv-virtualenv.

btw: there are tools like zsh-autoenv and others (see the references there in the README) that are better handling setting up envs.

Check out https://github.com/Tarrasch/zsh-autoenv#automatically-activate-python-virtualenvs to automatically activate any .venv.

(mentioned it already, so unsubscribing… 😉)

After a year of working in Python, I can come back to this issue and say a couple more things I’ve learned:

• Python version is pretty consistent across projects and the version of your dependencies is the more important thing. This is very different to someone from the Ruby or Node community where language runtime versions are more important.
• Virtualenv is usually a local thing on your computer and not committed to source control. We did use a virtualenv in production for one project, but the name of it didn’t matter.

For every python project I’ve worked on (usually scripts and daemons, not web apps), I’ve adopted the workflow of creating a virtualenv inside the project directory and activating it manually every time I’m working on the project. Forgetting to activate it or navigating between projects/directories while one env is activated can sometimes lead to accidental pip installs, etc, but those are pretty easy to reverse. I also don’t typically jump between projects much so this wasn’t a problem for me.

So, I think the main value-add of using this project is if you want to share virtualenvs between projects or if you want to store a virtualenv outside the project directory in some common location. That way, giving each virtualenv a name becomes useful and activating that env becomes useful.

I still think the file that this project reads should not be called .python-version, but that is a pretty minor point in the grand scheme of things.

Hope this helps!

I ended up writing my own plugin (in fish) that automatically picks up a .venv file which specifies the virtual env to use. It’s in my dotfiles, see pyenv.d and bin, if anyone is interested.

It’s only for python 3’s venv module though, since that’s what I use, but could be adopted for virtualenv as well.

I will commit the .python-version file, too, as is a common practice in the Ruby community.

The .ruby-version file isn’t only used by rbenv, either. For example, it’s respected by RVM (a predecessor of and “competitor” to rbenv that’s still popular) and Google App Engine depends on it.

@blueyed hmm, that is really different from Ruby world. There are a couple of things that seem weird to me:

1. that a python version is not usually defined for projects
2. There isn’t a reliable way to tell users or the shell what version of python should be installed.

Isn’t this a pain for people joining a new project? (regardless of whether they use pyenv).

I guess this question then isn’t really about pyenv then, and more about how Pythonistas manage versions at all 😕