Prompt showing "NO VERSION" for python and it takes a long time #6220
Replies: 2 comments 15 replies
-
|
@UID1 it seems you have pyenv installed which makes it run a bat file and that just fails: |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way to isolate the routine that actually interacts with the pyenv script that gives rise to this error so that I can download the golang environment myself and try to run that piece of code in a debugger and send you useful information that may help alleviate the issue? Maybe the string of the input argument is not terminated in a way that it should expect. Which version of PyEnv are you using? I'm using 3.13.3 that I installed with This also rases some questions as to what version of visualbasic you are using to run it. I think you use something that is different from the vbs engine that is used when I run vbs files from the shell. I tried this command: (Get-Item "C:\Windows\System32\vbscript.dll").VersionInfo.FileVersion In the shell which returned me ´5.812.10240.16384´. It is difficult for me to tell what kind of vbscript engine you are using in your code as I don't know golang very well. |
Beta Was this translation helpful? Give feedback.
-
|
@UID1 that's not how any of this works (in any language for that matter). Under the hood, golang leverages Windows syscalls who're responsible for executing the command and its arguments. In my case that would be For completeness, the vbscript version I have is |
Beta Was this translation helpful? Give feedback.
-
|
I'm actually on version I tried running the vbs script explicitly by I tried to run the command When running VBScript in "command line mode" it does output some more information and perhaps that messes with the RegExp filtration of the version string for python. Because in this mode omp freezes completely when cd:ing into a directory with python files. Perhaps showing the content of the https://github.com/pyenv-win/pyenv-win/blob/master/pyenv-win/libexec/pyenv.vbs |
Beta Was this translation helpful? Give feedback.
-
|
I tried writing the following code snippet that executes the package main
import (
"fmt"
"os"
"os/exec"
)
func main() {
home_path := os.Getenv("HOMEPATH")
command1 := "pyenv"
command2 := "cscript"
// Command 1 argument
argument := []string{"version-name"}
// Command 2 arguments
arguments := []string{
"/nologo",
home_path + "\\.pyenv\\pyenv-win\\libexec\\pyenv.vbs",
"version-name"}
fmt.Println()
fmt.Println("Testing running command 'pyenv version-name':")
RunCommand(command1, argument)
fmt.Println("Testing running vbscript")
RunCommand(command2, arguments)
}
func RunCommand(cmd string, args []string) {
cmd_h := exec.Command(cmd, args...)
out, err := cmd_h.Output()
if err != nil {
fmt.Println(err.Error())
}
fmt.Println(string(out))
}I'm using two approaches and both work. |
Beta Was this translation helpful? Give feedback.
-
|
We do exactly the same as your first example, there's no difference except for the timeout we add for 4 seconds (so check if your execution takes longer than that). If that's not the case, it'll for sure have something to do with access rights. |
Beta Was this translation helpful? Give feedback.
-
|
This is admittedly the first program I have ever written in go. I applied this modification to measure time: package main
import (
"fmt"
"os"
"os/exec"
"time"
)
func main() {
home_path := os.Getenv("HOMEPATH")
fmt.Println("Homepath is : " + home_path)
command1 := "pyenv"
command2 := "cscript"
// Command 1 argument
argument := []string{"version-name"}
// Command 2 arguments
arguments := []string{
"/nologo",
home_path + "\\.pyenv\\pyenv-win\\libexec\\pyenv.vbs",
"version-name"}
fmt.Println()
fmt.Println("Testing running command 'pyenv version-name':")
start := time.Now()
RunCommand(command1, argument)
end := time.Since(start)
fmt.Println("Command took :", end)
fmt.Println("Testing running vbscript")
start = time.Now()
RunCommand(command2, arguments)
end = time.Since(start)
fmt.Println("Command took :", end)
}
func RunCommand(cmd string, args []string) {
cmd_h := exec.Command(cmd, args...)
out, err := cmd_h.Output()
if err != nil {
fmt.Println(err.Error())
}
fmt.Println(string(out))
}When executing it, I get the following results: As can be seen, the first command takes over 10 seconds to execute. I examined further why On the old computer I had python version 3.12.7 and 3.9.6 and on the new one I have only 3.13.2 installed. So when issuing that command, it tries to access those python versions but when it cannot find them it tries to a search which is what is taking so much time for the command. So it successfully finds 3.13.2 on the new computer but not 3.12.7 and 3.9.6 which is not installed. I have spent some time trying to figure out why pyenv takes such a long time but I cannot find the source of the problem. The thing is almost all kind of interactions with |
Beta Was this translation helpful? Give feedback.
-
|
@UID1 we already cache outputs (or at least, that functionality is available using segment caching). I will not allow integrations to take > 4 seconds which is already way too long. Even git can respond the status in less than 1 second. I don't have this behaviour on my machine, and it should not be normal that this operation requires 10 seconds. Please file a bug report over at |
Beta Was this translation helpful? Give feedback.
-
|
I created this bug report: |
Beta Was this translation helpful? Give feedback.
-
|
I have gone through the files and it seems that the major bottleneck is in this file https://github.com/pyenv-win/pyenv-win/blob/master/pyenv-win/bin/pyenv.bat It is no specific line in there that takes more time than another, it is slow overall. Especially in the for-loops. Just to comment further on the VBScript program. It takes about 2.5 seconds to run it. Most of the time is spent on launching the VBScript engine which takes about 2 seconds. The remaining time is spent on the imports and declaration of functions. When that is done, the actual execution takes no more than 0.2 seconds. |
Beta Was this translation helpful? Give feedback.
-
|
I'd argue that vbscript might not be the right solution to the problem here. |
Beta Was this translation helpful? Give feedback.
-
|
When passing that set "fast_commands=version-name vname versions"
for %%a in (%fast_commands%) do (
if /i [%1]==[%%a] (
%pyenv% %* || goto :error
exit /b
)
)But I managed to reduce the time to slightly above 4 seconds. When running it with my go program I get: But with this setup your prompt just hangs or freezes as soon as I cd into a directory with py files. The only thing I can do is to close the command window and restart the shell. I tried writing a dummy bat file for pyenv like this @echo off
chcp 65001 >nul 2>&1
echo 3.13.2but then I get "NO VERSION" once again with much less delay. It should be noted that running just this simple 3-line bat files takes about 2.6 seconds. With my go program, there are no issues. It just extracts the version number and parses it out as shown above, with the dummy one as well as the modified pyenv.bat. I tried installing a trial version of JPSofts Take Command, or rather their TCC shell. With my modification, the bat files run much much faster there. Unmodified, it still takes time although a bit less. I looked a bit more deeply into the main pyenv.bat. The heart of the pyenv management takes place in the main pyenv.vbs that takes care of most of the commands. Other commands such as install, uninstall, duplicate, update, migrate, shell etc are taken care of by other bat or vbs files. The main purpose of the pyenv is to act as a hub and set up the necessities, validate file locations and forward to other script files of various formats. There is one quirk and that is in the All in all, it looks possible to migrate the main .bat file into say an exe binary built with golang but it will need to be able to manage environment variables to be exported to bat files it needs to launch. To me, it looks like the author is in the slow process of migrating from .bat to vbscript. |
Beta Was this translation helpful? Give feedback.
-
o I installed powershell 7, pyenv and omp on a fresh computer running Windows 11. When cd:ing into a directory where I have my python files, OMP suddenly takes a very long time to generate the command prompt and it fails to report the correct version of Python showing "NO VERSION" while I have no poblem getting the version string from both
python --versionandpython3 --version.After digging through documentation I found myself hopeless as to how to resolve this issue.
The following debug log should probably tell the rest of the story:
How can I trace out how the OMP parses the interactions with the python interpreter and where it goes wrong? This most likely is some bug though.
Beta Was this translation helpful? Give feedback.
All reactions