"... command exists in these Python versions" even if there is only one version.

[rnhmjoj]

Unfortunately I have encountered another problem.
I have installed python 2.7.5 with pyenv install 2.7.5 and then pyenv rehash
Now if I type python2.7 I get

pyenv: python2.7: command not found
The `python2.7' command exists in these Python versions:
2.7.5

I think this message should appear if there are others pythonx.y or pythonx version and the command is ambiguous but I have only one python version.
If I set pyenv local 2.7.5 then python2 or python2.7will start python correctly.

Am I missing something? Is possible to set the default pythonx version?

[yyuu]

You didn't miss anything. This is by the design of pyenv/rbenv.

The active version(s) should be set explicitly. I'm afraid that kind of implicit behaviour might introduce the confusions of Python versions on runtime. I don't like to change current behaviour.

[yyuu]

Though, there is still a chance to change this pyenv's default behaviour in its plugin. Since there is which hook in pyenv, injecting PYENV_COMMAND_PATH in plugin will change the command lookup strategy of pyenv.

https://github.com/yyuu/pyenv/blob/1a6eb80bcdc3a9746291291d7fe82f4eda36abe3/libexec/pyenv-which#L73

[rnhmjoj]

Sorry, I don't get it. What should I do exactly?

[yyuu]

Write pyenv plugin to hook pyenv which. See Authoring-plugins at Wiki.

I had have written somewhat similar plugin for rbenv, rbenv-which-ext. This is a plugin for rbenv, but it is very close to pyenv. Setting up following bash script as which hook will change the pyenv's command lookup strategy as you described.

if [ -n "$PYENV_COMMAND" ] && [ ! -x "$PYENV_COMMAND_PATH" ]; then
  versions=($(pyenv-whence "${PYENV_COMMAND}" 2>/dev/null || true))
  if [ "${#versions[@]}" -eq 1 ]; then
    PYENV_COMMAND_PATH="${PYENV_ROOT}/versions/${versions[0]}/bin/${PYENV_COMMAND}"
  fi
fi

[rnhmjoj]

I have never read that wiki page.
I made the hook and now pyenv is doing what I wanted.
Thank you again.

[yyuu]

Close this tasks since there're no tasks remaining.

If you decided to open source your plugin, please add it in Plugins at Wiki.

[mehcode]

Just what I needed, thanks. Made an open-sourced plugin out of this: https://github.com/concordusapps/pyenv-implict

[yyuu]

@mehcode 👍

[mehcode]

@yyuu All in my quest to get meld running in arch (rewrites the meld bin to use python2 instead of python) from within a virtualenv created by pyenv. Had to make this https://gist.github.com/mehcode/6172694 ... share the pain.

[jacobsvante]

I personally prefer being a bit more explicit. I have a directory ~/.pyenv-bin-overrides/ where I link bins that should be made global. My usage case is for tox to be able to find the different python versions. One example:

ln -s $(pyenv which python2.6) ~/.pyenv-bin-overrides

[blueyed]

@jmagnusson
I assume that you have ~/.pyenv-bin-overrides/ before the pyenv shims in your path then?

I have noticed that pyenv which python2.6 fails already, when using 3.4.1 via ~/.pyenv/version.

[jacobsvante]

@blueyed Unfortunately I don't remember because I no longer use pyenv. Sorry.

[blueyed]

For reference: this approach/plugin causes problems with tox (#214, concordusapps/pyenv-implict#2).

[cleocn]

pyenv local 2.7 3.4.7

it's work for me.

stavxyz/circleci-python-sandbox#1

[pedzed]

I'm afraid that kind of implicit behaviour might introduce the confusions of Python versions on runtime. I don't like to change current behaviour.

That's fine, but at least provide a more friendly error message? Now people are required to look the problem up themselves...

A simple

pyenv global 3.6.5

was what I was looking for.

[dmayle]

I develop my own command line tools in python in their own virtualenvs, so I want to be able to launch a shim in it's own environment if it exists in only one environment, so this is perfect for me. Here's a modified version of the script that can handle de-duping virtualenvs (e.g. a virtualenv called "MINE" shows up as both "MINE" and "X.Y.Z/envs/MINE")

if [ -n "$PYENV_COMMAND" ] && [ ! -x "$PYENV_COMMAND_PATH" ]; then
  # What versions are there for this command
  versions=($(pyenv-whence "${PYENV_COMMAND}" 2>/dev/null || true))
  dedup_versions=($(pyenv-whence "${PYENV_COMMAND}" 2>/dev/null || true))
  # Resolve symlinks in versions
  for index in ${!versions[*]}; do
    dedup_versions[$index]="$(greadlink -f "${PYENV_ROOT}/versions/${versions[$index]}")";
  done
  # De-dup the list of versions
  dedup_versions=($(echo "${dedup_versions[@]}" | tr ' ' '\n' | sort -u | tr '\n' ' '))
  if [ "${#dedup_versions[@]}" -eq 1 ]; then
    PYENV_COMMAND_PATH="${PYENV_ROOT}/versions/${versions[0]}/bin/${PYENV_COMMAND}"
  fi
fi

[agostbiro]

This is the simplest solution I've found to use 3.5-3.7 for testing with tox while using 3.6 as the default python:

pyenv install 3.6.6
pyenv install 3.5.6
pyenv install 3.7.0
pyenv global 3.6.6 3.5.6 3.7.0

After this:

python --version 
> Python 3.6.6

python3 --version
> Python 3.6.6

python3.6 --version
> Python 3.6.6

python3.5 --version
> Python 3.5.6

python3.7 --version
> Python 3.7.0

Hope this helps somebody!

[maffei2443]

Running

pyenv shell 3.X.X

before calling idle did solve the problem for me.

[petervandenabeele]

This is the simplest solution I've found to use 3.5-3.7 for testing with tox while using 3.6 as the default python:

pyenv install 3.6.6
pyenv install 3.5.6
pyenv install 3.7.0
pyenv global 3.6.6 3.5.6 3.7.0

After this:

python --version 
> Python 3.6.6

python3 --version
> Python 3.6.6

python3.6 --version
> Python 3.6.6

python3.5 --version
> Python 3.5.6

python3.7 --version
> Python 3.7.0

Hope this helps somebody!

Something I found is that by reverting the order of the setting of the pyenv global, a consecutive poetry install will by default pick the first one (the most recent/highest version, 3.11.3 here), which I prefer:

pyenv global 3.11.3 3.10.11 3.9.16 3.8.16

The reason I needed this is to run tox on these different versions (py38, py39, py310, py311).