Python version fetching takes >1 s [pyenv-win, powershell, win11]

[zEdS15B3GCwq]

Code of Conduct

• I agree to follow this project's Code of Conduct

What would you like to see changed?

In short: OMP seems to fetch the Python version by calling pyenv version-name, which can take >1 s to execute. This is an extremely long time to wait for the next prompt. Every time I press Enter (of course, it's only when there's Python involved). I understand that it's not OMP that's slow, pyenv is, but OMP could be smarter than to use it when not necessary, i.e. when a python.exe is accessible directly, which is when a virtual environment is active. So, when a venv is active, python.exe --version should be called first instead of pyenv.

More details, possible difficulties, implementation

My system: Powershell on Windows 11; Python versions managed by pyenv-win.

Full OMP debug log

Execution time breakdown:

Segments:

ConsoleTitle(true)                         -   0 ms
Time(true)                                 -   0 ms
Os(true)                                   -   0 ms
Session(true)                              -   5 ms
Root(false)                                -   0 ms
Git(false)                                 -   5 ms
Python(true)                               - 1234 ms
Rust(false)                                -   4 ms
Status(true)                               -   0 ms
Path(true)                                 -   5 ms
Battery(false)                             -   0 ms
Executiontime(false)                       -   0 ms

Run duration: 1.2366288s

Some python-related parts in the log:

[DEBUG] 22:51:21.704 terminal.go:FileContent:225 ↓
    home = C:\Users\Dev\.pyenv\pyenv-win\versions\3.13.2
    implementation = CPython
    uv = 0.6.12
    version_info = 3.13.2
    include-system-site-packages = false

[...]

[DEBUG] 22:51:22.924 terminal.go:RunCommand:293 → 3.13.2
[TRACE] 22:51:22.924 terminal.go:RunCommand(pyenv version-name) - 1.2207972s
[ERROR] 22:51:22.924 terminal.go:ResolveSymlink:205 → CreateFile versions: The system cannot find the file specified.
[TRACE] 22:51:22.924 terminal.go:ResolveSymlink(versions\3.13.2) - 0s
[ERROR] 22:51:22.924 language.go:setVersion:225 → CreateFile versions: The system cannot find the file specified.
[DEBUG] 22:51:22.924 terminal.go:CommandPath:310 → C:\Code\test\.venv\Scripts\python.exe
[TRACE] 22:51:22.924 terminal.go:CommandPath(python) - 0s
[TRACE] 22:51:22.924 terminal.go:HasCommand(python) - 0s
[DEBUG] 22:51:22.932 terminal.go:RunCommand:293 → Python 3.13.2
[TRACE] 22:51:22.932 terminal.go:RunCommand(python --version) - 8.0038ms
[DEBUG] 22:51:22.932 properties.go:GetString:28 → version_url_template: https://docs.python.org/release/{{ .Major }}.{{ .Minor }}.{{ .Patch }}/whatsnew/changelog.html#python-{{ .Major }}-{{ .Minor }}-{{ .Patch }}
[DEBUG] 22:51:22.932 text.go:patchTemplate:125 → https://docs.python.org/release/{{ .Data.Major }}.{{ .Data.Minor }}.{{ .Data.Patch }}/whatsnew/changelog.html#python-{{ .Data.Major }}-{{ .Data.Minor }}-{{ .Data.Patch }}
[TRACE] 22:51:22.932 text.go:Render(https://docs.python.org/release/{{ .Major }}.{{ .Minor }}.{{ .Patch }}/whatsnew/changelog.html#python-{{ .Major }}-{{ .Minor }}-{{ .Patch }}) - 0s
[DEBUG] 22:51:22.932 properties.go:GetString:28 → cache_duration: none
[DEBUG] 22:51:22.932 text.go:patchTemplate:125 →   {{ if .Data.Error }}{{ .Data.Error }}{{ else }}{{ if .Data.Venv }}{{ .Data.Venv }} {{ end }}{{ .Data.Full }}{{ end }}
[TRACE] 22:51:22.932 text.go:Render(  {{ if .Error }}{{ .Error }}{{ else }}{{ if .Venv }}{{ .Venv }} {{ end }}{{ .Full }}{{ end }} ) - 0s

My interpretation is that pyenv version-name was called, which took 1.22s this time. Then perhaps python --version was also called? That only took 8ms. Not sure this means it was called or not. Nevertheless, python.exe --version is much faster than pyenv version-name, this can be tested easily by invoking them. I'm writing python.exe specifically, to avoid calling the pyenv shim.

Since it isn't really OMP's fault, I don't expect OMP to do very complicated things to work around this. My idea is that when we're in an active virtual environment, OMP should call python.exe --version instead of pyenv. It's a reasonable expectation that there's a python executable directly available in a virtual environment, and that it's the correct one to call, even with pyenv present.

I'm not very familiar with situations where the python executable inside a venv has a name different from python.exe. Is it possible? Assuming the possibility that it could be named python3.exe or something else, it might be necessary to have a configuration option to specify the python executable's name. For example, it could be named python_binary as per the similar option in Starfish.

For situtations other than inside an active venv, accessing a/the Python executable directly could be problematic. I don't think that there's a quick solution except for calling pyenv, which is very slow. For such cases, I think it's reasonable to expect the user to either put up with the delay, or change the settings (display_mode or fetch_version) to prevent version fetching.

[JanDeDobbeleer]

@zEdS15B3GCwq the issue was that PYENV_ROOT is empty and we should never validate in that case.