native-api

I _guess_ there could be an option envvar added to prefer Virtualenv even if Venv is present. That's because the current logic is that there's no need for Virtualenv if...

This means that you haven't run `eval "$(pyenv init -)"` in the current shell. `pyenv activate` requires `pyenv` to be a shell function. The current message is misleading as it...

> eval "$(pyenv init - --path)" This is a wrong command. Check the README.

Please see updated and hopefully clearer Pyenv shell setup instructions in https://github.com/pyenv/pyenv#readme `eval "$(pyenv virtualenv-init -)"` should run in an rc file after `eval "$(pyenv init -)"` as before.

Updating to the latest tag is possible. It wouldn't have saved you from the breakage caused by 2.0.0 though since that was an intentional breaking change.

> It wouldn't have saved you from the breakage caused by 2.0.0 though As such, I don't see what this would achieve. We keep `master` stable and just slap tags...

To find out what takes time, we need to get a debug trace of what's running while you perform those actions and how long it takes. For the first point...

> just pressing enter with empty input in shell results in a small yet very noticeable delay before next prompt. With the code I gave, you should've also seen the...

Try localizing the issue by timing the code that runs at prompt with: ```bash export PS4='+($(date "+%s.%N")) (${BASH_SOURCE:-}:${LINENO}): ${FUNCNAME[0]:+${FUNCNAME[0]}(): }' set -x set +x ```

If the culprit is a Pyenv subcommand, also `export PYENV_DEBUG=1` and replace `PS4` in `pyenv`'s source code to the above value to get its timed trace as well.