VUnit-by-HGB seems to ignore virtual environments

[philipphct]

Disclaimer

First of all, lovely plugin, me - and my team - use it almost every day, and love to see the improvements over "hbohlin.vunit-test-explorer" :)
Previously we used vunit and this plugin in a systemwide installation and did not bother with virtual environments and such. But as time passes, it gets increasingly difficult to ensure everyone is on the same page. So I did some investigations regarding using virtual environments and here is what I found.
In case I simply missconfigured something, I would be glad to hear from you whats wrong :)

P.S.: This is my corporate github account, so I am currenty kinda inofficially speaking in the name of that corporation. So in case that is a turnoff for you, I totally understand.
Unfortuately I have zero experience with Typescript and VSCode Plugin development, otherwise I could give it a try.

Anyway, those are the findings I did not want to rot away in internal wiki;

Setup

A clean python installation and configured a python virtual environment with CTRL + Shift + P -> Python: Create Environment -> VENV-> Python3…. -> requirements.txt

Configured in User Settings:

"python.terminal.activateEnvInCurrentTerminal": true,

What I already tried

Sanity Checking my setup

Running a run.py within a terminal window inside VSCode does work. -> Virtual environment itself seems OK

Configuring Default Python Interpreter

Configuring the default Python Interpreter Path in Workspace Settings relative to current working dir

    "python.defaultInterpreterPath": ".venv/Scripts/python.exe"

does not have any effect, i.e. this plugin seems to ignore that setting.

Relative Path in Plugin Settings

Configuring a relative path to the virtual environments python executable like any variation of those:

"vunit-by-hgb.python": "./venv/Scritps/python.exe",

"vunit-by-hgb.python": ".\\venv\\Scritps\\python.exe",

"vunit-by-hgb.python": "${workspaceFolder}/.venv/Scritps/python.exe",

"vunit-by-hgb.python": "${workspaceFolder}\\.venv\\Scritps\\python.exe",

does not work either with this output:

Running VUnit: ./venv/Scritps/python.exe "d:\dev\path\run.py" --no-color --exit-0
Der Befehl "." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
or similar.

Absolute Path to python executable

Using absolute path in workspace settings

"vunit-by-hgb.python": "D:/dev/path/.venv/Scritps/python.exe",

Works perfectly fine, but kind of a hassle.

System Information

OS	Windows 10/11
Python	3.12
VSCode	1.91.1

[jakobjung10]

Hi @philipphct,

Thank you for the issue!

I don't know how smart this feature should be...

Should the property "vunit-by-hgb.python" be deprecated and the extension completely relies on the property "python.defaultInterpreterPath" ?
Should "vunit-by-hgb.python" serve as a fallback for "python.defaultInterpreterPath"?
Should the user be able to choose between the two settings with another new setting like "vunit-by-hgb.pythonPathMode"?
Should the user specify if the interpreter-path is absolute or relative or should the extension try to automatically resolve relative paths, but still detect if a global interpreter path is used?
Should the extension automatically take care of the .exe-file-ending on windows?

In relative paths, variables like ${workspaceFolder} cannot be used as the vscode-api doesn't offer any functionality to resolve these variables inside a path, as far as i know...
Of course, i could rebuild this functionality but it is not worth the effort.

The problem is that the smarter this feature gets the more edge cases will arise where the feature won't work as expected without the user being able to understand the problem...

What is your opinion, @philipphct ?

[philipphct]

Hi @jakobjung10,
thanks for replying, ans sorry in advance for this messy answer. It is a product of multiple iterations.

The problem is that the smarter this feature gets the more edge cases will arise where the feature won't work as expected without the user being able to understand the problem...

I wholeheartedly agree.

In relative paths, variables like ${workspaceFolder} cannot be used as the vscode-api doesn't offer any functionality to resolve these variables inside a path, as far as i know...

Thats unfortunate, I was hoping for some already existing builtin resolution function, to deal with such user inputs.

Of course, i could rebuild this functionality but it is not worth the effort.

Yes, that would be way too much.

Should the extension automatically take care of the .exe-file-ending on windows?

Hmm, I don't think so. I would assume Windows users are already used to manually deal with this ".exe" file extention? see below.

Should the property "vunit-by-hgb.python" be deprecated and the extension completely relies on the property "python.defaultInterpreterPath" ?
Should "vunit-by-hgb.python" serve as a fallback for "python.defaultInterpreterPath"?
Should the user be able to choose between the two settings with another new setting like "vunit-by-hgb.pythonPathMode"?
Should the user specify if the interpreter-path is absolute or relative or should the extension try to automatically resolve relative paths, but still detect if a global interpreter path is used?

In the meantime I found this wikipage regarding python.defaultInterpreterPath:

My interpretation is, that "python.defaultInterpreterPath" would be

• irrelevant anyway, as soon as a Interpreter (via Python: Select Interpreter or implicitly via creating and loading into a virtual environment) is selected
• My approach not within the intended scope of that parameter

From the wikipage:

For 3rd party extensions that need access to the Python path, you can retrieve it using the extension API. It's also possible to retrieve it using the command ${command:python.interpreterPath}

The last part may be a not that interesting (see your comment "..api doesn't offer any functionality to resolve these variables.."), but the first one could be interesting?
The Python Plugin seems to provide its internally selected Python interpreter (be it the fallback to a default or an explicitly selected one). So maybe the snippet(s) linked in this issue 11294 and issue 12596 could lead to something?

If that is something that could work, i guess it would also

• avoid dealing with OS specific things
• "vunit-by-hgb.python" could be deprecated in favor of this Extension API
• avoid some path resolution and handling (relative vs. absolute)

Sorry for the inconvenience.

What do you think?