Open blueyed opened 9 years ago
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
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).
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 https://github.com/sstephenson/rbenv/issues/187
pyenv support multiple versions.
It will try the versions in order.
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):