'`
1) If people are using bash with `set -u` (enable unset variable
checking), then they will get an error if they run `pyenv` in the
CLI under the current setup. To avoid any errors when no positional
arguments, we use ${1:-} instead of $1.
2) We find that the script looks better when using:
```bash
echo \
'pyenv() {
local command=${1:-}'
```
As opposed to:
```
echo 'pyenv() {
local command=${1:-}'
```
In `test_helper.bash`:
set
PATH="${BATS_TEST_DIRNAME%/*}/libexec:$PATH"
instead of
PATH="${BATS_TEST_DIRNAME}../libexec:$PATH"
it essentially enables us to expect
`${exec_root}/completions/pyenv.bash`
instead of something like
`${exec_root}/test/../completions/pyenv.zsh
Homebrew installations have PYENV_ROOT set to `~/.pyenv`, while the
actual completion file resides in /home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23/completions/pyenv.zsh
Thus, if you try to use `$PYENV_ROOT/completions/pyenv.${shell}`, the
completions file will not be found, since you are pointing to:
`~/.pyenv/completions/pyenv.zsh`
when the actual location is:
`/home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23/completions/pyenv.zsh`
This problem is resolved by using the parent folder of the currently
executing file:
`/home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23/libexec/pyenv-init`
which is
`/home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23`
And then go to completions from there.
I don't like the fact that homebrew installations store some things in
`/home/linuxbrew/.linuxbrew/Cellar/pyenv/2.4.23/libexec/pyenv-init`
while stuff like `shims` and python versions are stored in `~/.pyenv`, but
that's how it currently is.
The old tests seems to have been copy-paste from some 11 year old
rubyenv setup, and included a long and windy pathname. The old setup was
extremely bad in my view, current test is much better.
Exported variables are local to the specific test, so they will not
affect other test instances.
---> Enables us to remove unnecessary `root` variable in pyenv-init.
pyenv-init.
- It turns out that the code I wrote was very similar to what was
already present in rbenv-init.
As rbenv is referenced when I am writing a pull request, I am assuming
that maintainers want code similar to what's already there.
WARNING:
The code will now not validate whether the specified shell is valid or
not, and if you make a silly mistake like writing `--parh` instead of
`--path`, the shell may be set to `--parh` and so forth. But I guess
this is acceptable.
- Local testing shows that you get a trivial 1.6x speedup in command execution
time (over doing `pyenv init -`) by specifying which shell you are using.
handling for case where unknown option is provided.
- Error handling involves writing error message to stderr, and
forcefully exiting the init script, forcing user to fix their setup.
Requested in https://github.com/pyenv/pyenv/issues/2680
for deployments with a stock `.pyenv-version` that can use any
of a number of Python versions
and for compatibility with `uv`.
* Support `pyenv local --force`
* Support `pyenv-version-file-write --force`
* Support `pyenv version-name --force`
* Ignore missing versions when searching for executables
* Display "commmand not found" even when there are nonexistent versions
* exec.bats: replace `python` and `rspec` with something that doesn't exist globally, either
in Ubuntu Github CI, `python` exists globally
* Reorganize readme, add gif
1. Details in 'Getting Pyenv' and 'Setup for your shell' are collapsed. User can expand relevant
sections depending on their platform and shell.
2. 'How It Works' and 'Advanced Configuration' are moved to the bottom of the README.md
just before 'Contributing' section at the end.
3. Added a GIF in the 'Usage' section to showcase
- Listing python versions available for install.
- Installing a specific python version.
- Listing installed python versions.
- Switching to another python version for a directory.
- Testing by moving terminal into the directory and moving back.
* Update GIF to show prefix resolution
* Collapse upgrade notes
* Cross-mention Linux and MacOS instlalation scenarios
---------
Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>
