Venvs created from system Python are directories, not sym links. The previous
code only displayed venvs that were a directory and a symlink. Now check for
directory existence and symlink status, or directory existence and the presence
of bin/activate within the directory.
Use the code from pyenv-versions for efficiency and consistent output.
The main performance problem was in the call to pyenv-virtualenv-prefix,
which called pyenv-prefix, which then enumerated every virtual environment.
This was done inside a loop, compounding the problem.
Simply the virtual environment listing so that it does not have to call
pyenv-virtualenv-prefix anymore.
Just using paths relative to ${BASH_SOURCE} to access `libexec`
fails if the scripts are symlinked to a location,
such as when installed with Homebrew,
since the `libexec` directory is not linked into `brew --prefix`.
Implement a simple version of `realpath`
and run `${BASH_SOURCE}` through it.
This gets the actual installation directory
relative to which `libexec` is located.
Co-authored-by: Andrew Christianson <achristianson@edmunds.com>
pyenv-virtualenvs could not list conda environments & pyenv shell would only activate the base conda environment
the conda detection criteria of testing the presence of `conda` or `activate` files under `$(pyenv root)/versions/$version/bin` appears to be the culprit, since newer environments no longer include these files: those files reside in the base conda environment
- add detection criteria of `$(pyenv root)/versions/$version/conda-meta`
- compute the real prefix to the base environment from `realpath $(realpath $(pyenv root)/versions/$version)/../..`
- to allow that, enhance substitute `realpath` in `pyenv-virtualenvs` to reduce relative paths `.` & `..`, and factor that code out to a file under `libexec` for reuse
- hook `which` to locate conda from the real prefix
