You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new way of setting the python interpreter has "broken" our internal development for an embedded python interpreter.
Right now we opt out from the experiment but I personally like the change, but would need some extra APIs to restore the workflow.
What is the problem
We have an inhouse tool which has an embedded python interpreter (different compiler than the regular cpython distribution). We use all the feature like debugging, Pylance and so on via this python extension. Because our embedded python interpreter is an plugin, the path to the interpreter slightly change on a more or less regular basis. We have our own VSCode extension which fix all the problems for the user when something change and user love that feature.
The new way makes it impossible (without user interaction) to set the interpreter from our extension.
How to solve the problem
I would be awesome when this extension would extend the existing python.setInterpreter command to accept one argument, so that an extension can set the interpreter path via an API. Right now the command just open the selection box to select the interpreter. It would also be great to have a command which return the interpreter path like python.interpreter.
The cmake extension already use that kind of get/set mechanism, which I use in my Qt-tool extension
The use of the API could look like
// set the interpreter via codeawaitvscode.commands.executeCommand("python.setInterpreter","C:\\pathtomyinterpreter.exe");// get the selected interpreter pathconstinterpreterPath=awaitvscode.commands.executeCommand("python.interpreter")asstring;
area-environmentsFeatures relating to handling interpreter environments
2 participants
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hi,
The new way of setting the python interpreter has "broken" our internal development for an embedded python interpreter.
Right now we opt out from the experiment but I personally like the change, but would need some extra APIs to restore the workflow.
What is the problem
We have an inhouse tool which has an embedded python interpreter (different compiler than the regular cpython distribution). We use all the feature like debugging, Pylance and so on via this python extension. Because our embedded python interpreter is an plugin, the path to the interpreter slightly change on a more or less regular basis. We have our own VSCode extension which fix all the problems for the user when something change and user love that feature.
The new way makes it impossible (without user interaction) to set the interpreter from our extension.
How to solve the problem
I would be awesome when this extension would extend the existing
python.setInterpretercommand to accept one argument, so that an extension can set the interpreter path via an API. Right now the command just open the selection box to select the interpreter. It would also be great to have a command which return the interpreter path likepython.interpreter.The cmake extension already use that kind of get/set mechanism, which I use in my Qt-tool extension
The use of the API could look like
Greetings
Michael
All reactions