Improve error message when command was not found

[axelpale]

The problem that led to Issue #34 and this question in Stack Overflow is easily fixed by a better error message.

Currently if no .python-version exists in the current directory, the following message is printed:

$ python2.7
pyenv: python2.7: command not found

The `python2.7' command exists in these Python versions:
  2.7.10

The message does not inform user in any way what is wrong and what should be done to fix the situation. For me and my employer, I have lost about one hour of work to figure out what was wrong. Therefore my employer just lost about 20 dollars because the poor error message.

Hence, I suggest the following alternative message:

$ python2.7
pyenv: python2.7 is not listed in the local python versions.

The `python2.7' command exists in these Python versions:
  2.7.10

To make python2.7 available, append 2.7.10 to your .python-version file

[yyuu]

The message doesn't mean you're required to prepare .python-version. It just means it is written; the named executable is not found in currently activated versions. Your fix is just misleading.

[axelpale]

Thanks for your quick reply @yyuu. However the issue still remains. Probably I do not understand the whole picture here but I'm sure I'm not alone.

Do you agree that the current error message does not help users to solve the problem in any way? Of course for the designer of the pyenv the error is obvious but for a user like me who has used pyenv only for a half a year, it is not obvious.

Would a better error message be:

$ python2.7
pyenv: python2.7: command not found.

The `python2.7' command exists in these Python versions:
  2.7.10

To make python2.7 active, append 2.7.10 to your .python-version file by 'pyenv local 2.7.10'.

[Flimm]

I agree with @axelpale that the currently implemented error message is confusing.

[blueyed]

The error message could be improved, yes.
But it should be more generic, and then it's the basics of pyenv after all.

The `python2.7' command exists in these Python versions:
  2.7.10

You can use it by activating one of those versions using 'pyenv local',
'pyenv shell' etc.

[dingus9]

It's odd to me that this would be designed this way, all installed versions show up in my path. I can tab complete python>> and see all pyenv installed versions, but the shims return an error message. Versions that cannot be executed should not show up on the path or pyenv should default to whatever is set for the current scope, or fallback to anything available e.g. python3.5 would always refer to some python3.5 if one is available.

The current functionality makes python version availability detection in scripts more convoluted because now you have to execute the shim and check for a return code... but executing python would require you to now run the pythonx.y --version binary etc. Makes version detection more complicated then a simple if which python3.5 paradigm. This is also just be annoying when moving around in directories etc.

Looking in to a way around this still

[blueyed]

The current functionality makes python version availability detection in scripts more convoluted because now you have to execute the shim and check for a return code

Using python -V also works to check this.

I think it makes sense to not activate all versions by default, since you might have dozens (e.g. when using pyenv-virtualenv etc).
It's good to enable the ones to use explicitly then (you can enable multiple at the same time).
IIRC there is a plugin (or there could be one) that enables all versions by default.