"... command exists in these Python versions" even if there is only one version. about pyenv HOT 19 CLOSED

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.

from pyenv.

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!

from pyenv.

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

from pyenv.

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.

from pyenv.

pyenv local 2.7 3.4.7

it's work for me.

stavxyz/circleci-python-sandbox#1

from pyenv.

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

from pyenv.

Running

pyenv shell 3.X.X

before calling idle did solve the problem for me.

from pyenv.

Close this tasks since there're no tasks remaining.

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

from pyenv.

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

from pyenv.

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).

from pyenv.

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

from pyenv.

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

from pyenv.

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

from pyenv.

@mehcode 👍

from pyenv.

@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.

from pyenv.

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

from pyenv.

@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.

from pyenv.

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

from pyenv.

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

from pyenv.