Closed Syphdias closed 5 years ago
Question: Why not use pyenv global
?
@Syphdias Your simplification slows down the virtual environment detection dramatically. Get python version from PYENV_VERSION
is much faster than pyenv version-name
. The similar thing happens with rbenv
and nodenv
.
❯ time (pyenv version-name)
2.7.16
0.05s user 0.04s system 96% cpu 0.097 total
❯ time (echo $PYENV_VERSION)
2.7.16
0.00s user 0.00s system 59% cpu 0.001 total
pyenv version-name
is just an implementation of the version detection logic:
PYENV_VERSION
.python-version
${PYENV_ROOT}/version
There's some overhead of pyenv version-name
compared with checking PYENV_VERSION
directly.
There's some overhead of
pyenv version-name
compared with checkingPYENV_VERSION
directly.
The expected behaviour is, that the segment spits out the same output as the command to check the version. Otherwise, false information is provided by the segment that might confuse a user. To get exactly that behaviour you need every logic handled by pyenv version-name
. How do we get this exact behaviour now?
If you choose 2 you can improve performance if there is unnecessary overhead. It's not true that performance improvements cannot be done with 1. You could utilize techniques like caching or prefetching to get the output faster.
The old implementation did not reimplement all the logic that is used by pyenv version-name
thus proving false output. That's why I decided to remove the shortcut. Of course, you could go with the current version as a compromise of speed and wrong output.
@Syphdias Obviously, I'm not that insane to implement every logic again by myself. I'm only indicating you should check PYENV_VERSION
first, then fallback to pyenv version-name
.
you should check
PYENV_VERSION
first
As mentioned in #1281 PYENV_VERSION
cannot be trusted. And it is a compromise. There are pros and cons to trusting PYENV_VERSION
anyways.
I'm not a user. I cannot decide which one is the better version. The current version just has less unexpected behaviour.
Closing this PR since #1285 makes this one redundant.
@laggardkernel, I'll leave it to @bhilburn which one he thinks is best for users, since the current version does have its drawbacks as well.
Sorry to bother you. I didn't realize there was another related pr being merged. It seems my words is too late.
I was a bit confused to find
__p9k_$1_prompt_segment
here...This produced the wrong segment content, e.g.
systemblack
. Also resolves #1280 by not displaying the version if it is "system" andP9K_PYENV_PROMPT_ALWAYS_SHOW=false