Make the fish prompt faster

[rharish101]

This speeds it up using two methods:

• Run the hook _pyenv_virtualenv_hook only when $PWD or $PYENV_VERSION change. This was taken from https://github.com/pyenv/pyenv-virtualenv/issues/338#issuecomment-1366158648. Note that this doesn't automatically work when you open a shell in a directory, so this is manually called during shell init.
• Inside the hook, run the pyenv (de)activation in the background. Thus, this doesn't block the rest of the shell.

This fixes #338.

[native-api]

• Run the hook _pyenv_virtualenv_hook only when $PWD or $PYENV_VERSION change.

What about pyenv local? Or otherwise changing the version files (e.g. from another shell).

What does the hook actually spend much time on? And how much? Could you provide a profile trace?

[rharish101]

What about pyenv local? Or otherwise changing the version files (e.g. from another shell).

Good point; I hadn't thought of that. I'll try to figure out something, if possible.

What does the hook actually spend much time on? And how much? Could you provide a profile trace?

Sure, here are 10 profile traces of the original _pyenv_virtualenv_hook I took inside a Python project with a .python-version file specified: profile-01.txt profile-02.txt profile-03.txt profile-04.txt profile-05.txt profile-06.txt profile-07.txt profile-08.txt profile-09.txt profile-10.txt

[native-api]

According to the profiles, almost all the time is spent on an external command (I presume, sh-activate):

14 145977 > _pyenv_virtualenv_hook <...> 257 133162 -----> pyenv "sh-$command" $argv|psub <...> 128748 128748 -------> command pyenv "$command" $argv

So your assessment that we can save lots of time by not calling it in some cases is correct.

Though I also see that

• this logic is very dumb (just blindly calls activate regardless of whether that makes sense -- and even deactivate if that fails, for some reason)
• it seems to call both pyenv "sh-$command" and command pyenv "$command" -- whch isn't supposed to happen

[native-api]

Though I also see that

• this logic is very dumb (just blindly calls activate regardless of whether that makes sense -- and even deactivate if that fails, for some reason)

• it seems to call both pyenv "sh-$command" and command pyenv "$command" -- whch isn't supposed to happen

Which suggests that rather than potentially duplicating existing logic, a more productive way forward might be to concentrate on studying it first -- to find out if it works as intended to begin with and whether it does extraneous work.

E.g. if the external pyenv executable is actually called each time, we should save a lot of time just by fixing that.

[native-api]

We aren't merging anything that breaks things. Or we'll be swamped in bug reports that things no longer work and will have to fix that pronto in addition to reputational damages.