Use installed version from .python-version even if not all versions are installed?

[cquick01]

Hi, this isn't really a build issue so I got rid of the template... I tried asking on Gitter also but didn't get a response.

$ pyenv --version
pyenv 2.3.17-4-gb3c91b37

I have a project that supports Python 3.9+, so I have a .python-version file that contains

3.11
3.10
3.9

in an effort to allow machines that have 3.11 installed to use that, otherwise 3.10, otherwise 3.9. But this doesn't work on machines that don't have all three versions installed. It gives an error for instance if 3.10 is not installed

pyenv: version `3.10' is not installed (set by /home/user/project/.python-version)

Is it possible to configure pyenv to just use one of the defined versions from .python-version if it is installed, rather than requiring all the defined versions to actually be installed? I'd hope that in the above example, it would see 3.11 and 3.9 are available, and use one of them (preferably whichever is defined earlier in the .python-version file, 3.11).

Thanks in advance!

[native-api]

Not possible now without workarounds:

pyenv/libexec/pyenv-version-name

Lines 53 to 54 in b3c91b3

	if [ "$any_not_installed" = 1 ]; then
	exit 1

A workaround is to create dummy (empty) 3.11 and 3.10 directories under $(pyenv root)/versions.

[cquick01]

Thanks, that gets things working for now since we control each of the machines our app runs on. It isn't super portable outside of a closed environment though, like for open-source projects for instance.

Any chance the original workflow could get supported? I'm actually surprised not to have found much other discussion about it. I'd have figured the intuitive thing to do would choose an interpreter that is available and only give an error if all can't be found. I tried digging through the code a bit myself but couldn't get it working so far.

[native-api]

Of course we can support it. We just need to decide how exactly.

I think that

• executable resolution should work without errors or warnings
  • as this corresponds to the current logic of selecting the first version that has the requested executable
• pyenv local should error unless -f is passed.
• pyenv version should still print an error

[cquick01]

I agree with each of those points. pyenv version looks good as is. Also like the idea of adding a -f arg for pyenv local to force writing the .python-version file even if not all versions are found. pyenv local without any args should still print the versions from .python-version without any errors.

pyenv prefix shows an error when a version is missing, too. Should it list available versions, or print an error, or both?