Support for multiple activated versions

[Daniel Hahler]

pyenv support multiple versions.

It will try the versions in order.

% python --version
Python 3.4.3

% pyenv shell 2.7.9:3.4.3
% python --version
Python 2.7.9


% pyenv version
3.4.3 (set by /home/user/.pyenv/version)
2.7.9 (set by /home/user/.pyenv/version)

% cat .pyenv/version
3.4.3
2.7.9

% pyenv version-name 
3.4.3:2.7.9

% pyenv versions 
  system
  …
* 2.7.9 (set by /home/daniel/.pyenv/version)
  …
* 3.4.3 (set by /home/daniel/.pyenv/version)
  …

When trying to run a shim from a version that's not activated, you'll see
a list of versions where it is available (that might be the case for
rbenv/anyenv already):

% easy_install-2.6 
pyenv: easy_install-2.6: command not found

The `easy_install-2.6' command exists in these Python versions:
  2.6.9

[Mislav Marohnić]

Interesting, thanks for letting me know. Why is this feature baked into pyenv? Doesn't it make it difficult to be certain about which exact version will be used for running a python program? To me it seems that the whole point of a rbenv-like manager is to lock a version down with absolute precision. Thanks

[Daniel Hahler]

In Python you often have to run Python 2 and 3 in parallel.

Apart from that, there are tools like tox, which run tests in different Python versions, and that needs to have them available, too.

If you use python you'll get the first/locked version, but the other versions might provide the other interpreter (python-2.7), or some tool, which was installed using pip2 (instead of pip or pip3).

Then there are also virtualenvs, which are handled like versions through https://github.com/yyuu/pyenv-virtualenv.

So you can use venv-name:3.4.3 as your pyenv-version, which would use the virtualenv, but fall back to your 3.4.3 version (for running shims).

[Mislav Marohnić]

If you use python you'll get the first/locked version, but the other versions might provide the other interpreter (python-2.7), or some tool, which was installed using pip2 (instead of pip or pip3).

Wow, that's… confusing. But it sounds like this fallback could theoretically be done via a python-specific plugin for anyenv. The whole idea of the fallback if an executable isn't found in the current version reminds me of rbenv/rbenv#187