mpremote installation check when using a virtual environment

[erikdelange]

Setup:

• Python 3.11 installed system wide, without any additional modules
• A virtual environment (c:/Users/Zeus/OneDrive/Documenten/Projecten/Python/Virtual Environment/MicroPython) containing a.o. mpremote.py
• Python interpreter in VS Code pointing to the virtual environment

The first time a command from the MPRemote extension is run it checks whether Python module mpremote.py is installed. This check is done using the global Python interpreter, and does not consider a virtual environment. As a consequence people using a virtual environment get a popup with message 'mpremote is not installed or could not be run as a Python module'. The selected command fails (terminal message: No module named mpremote). However a terminal called 'mpremote' is opened and this activates your virtual environment. And thus the next time you start a command it is executed flawlessly. So the error message has no consequence (except for the first command executed), and is a bit confusing.

Perhaps could be changed to first opening the mpremote terminal, which will activate the virtual environment, and only then execute the check whether mpremote.py is installed.

Example: content of the mpremote terminal in the situation where command 'Scan for attached devices' is executed twice. The first attempt fails, the second one succeeds.

PS C:\Users\Zeus\OneDrive\Documenten\Projecten\MicroPython\Resilient Wifi Connection> py.exe -m mpremote devs
C:\Program Files\Python311\python.exe: No module named mpremote
PS C:\Users\Zeus\OneDrive\Documenten\Projecten\MicroPython\Resilient Wifi Connection> & "c:/Users/Zeus/OneDrive/Documenten/Projecten/Python/Virtual Environment/MicroPython/Scripts/Activate.ps1"
(MicroPython) PS C:\Users\Zeus\OneDrive\Documenten\Projecten\MicroPython\Resilient Wifi Connection> py.exe -m mpremote devs
COM1 None 0000:0000 (Standaardpoorttypen) None
COM6 DQ008V27A 0403:6015 FTDI None
(MicroPython) PS C:\Users\Zeus\OneDrive\Documenten\Projecten\MicroPython\Resilient Wifi Connection> 

[DavesCodeMusings]

I can try switching things around so the terminal window is activated first. But, I don't use Python virtual env, so I have no way of testing. Is it just the opening of the terminal that activates the virtual env or do you have to run a Python command inside that terminal to make it work?

[erikdelange]

Activation of the virtual environment is done automatically. Looking at the terminal output I copied in the issue it is the line with the ampersand on the first position. VS code does detect that a virtual environment is used as Python interpreter, and when opening a new terminal injects the activation command. Works with every terminal you open. So first activating the terminal window (without any command) might work.

Op wo 14 jun 2023 om 06:52 schreef Dave @.***>:

I can try switching things around so the terminal window is activated first. But, I don't use Python virtual env, so I have no way of testing. Is it just the opening of the terminal that activates the virtual env or do you have to run a Python command inside that terminal to make it work?

— Reply to this email directly, view it on GitHub https://github.com/DavesCodeMusings/mpremote-vscode/issues/4#issuecomment-1590464895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF43YWYKUVVRL3EMELMTRMLXLE7SPANCNFSM6AAAAAAZBXFEAU . You are receiving this because you authored the thread.Message ID: @.***>

[DavesCodeMusings]

Thanks for confirming.

[DavesCodeMusings]

@erikdelange The order has been switched so the terminal is open before checking on the mpremote module. Hopefully that fixes it. Please test with the 1.20.9 version of the extension when you can.

[erikdelange]

Unfortunately switching the order has not made a difference. in version 1.20.9 Tested again by running the 'Scan for attached devices' command (shown as py.exe -m mpremote devs in the terminal output) twice. The results are the same; when executing the command for the first time the mpremote terminal is openend, but the virtual environment is only activated after the command has run (and failed). As you mentioned you don't use virtual environments I'll try to setup a VS Code extension dev environment to do some experimenting. But that will be in three weeks after I've returned from my holiday.

For reference, the Powershell terminal which is openend automatically when starting VS Code shows this:

[DavesCodeMusings]

Just curious. Do you see something like the screenshot below associated with your mpremote terminal? Specifically the warning triangle. This example is from git, but I wonder if your Python virtual env might be doing the same kind of thing. It wants to "relaunch the terminal" to active the integration.

[erikdelange]

The messages are similar, however no warning triangle. Also, I see no reference to the virtual environment in any of the messages.

I do notice in the new version the mpremote terminal is now opened automatically when starting VS Code. Nifty. But the mpremote version check is still done when py.exe points to the global python interpreter, so before the virtual environment is activated.

Under the hood the activate() function in extension.js is called before the virtual environment is activated. I found no way to postpone running of the activate() function, I think that is just how VS Code works. The crude solution I'm using now is to modify mpremote.js after installation or update and remove the mpremoteVersion check.

[DavesCodeMusings]

If I created a configuration parameter that allows you to specify the path to your python interpreter, would that help? In this scenario, when the parameter is set, the mpremote extension would use that path instead of py.exe. If it's not set, it would default to the same behavior as now, which is to try py.exe.

[erikdelange]

I think that would defeat the idea of using a virtual environment which is meant to hide the hassle of having to select a specific interpreter.

Perhaps it would be possible to skip the mpremote version check on startup based on the existence of a config parameter. It it is not there - being the default situation - retain the current check, if it is there then skip the check. Assuming a user knows what he is doing when setting this new config parameter this could work.

Op wo 12 jul 2023 om 23:39 schreef Dave @.***>:

If I created a configuration parameter that allows you to specify the path to your python interpreter, would that help? In this scenario, when the parameter is set, the mpremote extension would use that path instead of py.exe. If it's not set, it would default to the same behavior as now, which is to try py.exe.

— Reply to this email directly, view it on GitHub https://github.com/DavesCodeMusings/mpremote-vscode/issues/4#issuecomment-1633246955, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF43YW7SRUMOXXNT76HGLVTXP4KSZANCNFSM6AAAAAAZBXFEAU . You are receiving this because you were mentioned.Message ID: @.***>

[DavesCodeMusings]

Yes, I should be able to make a boolean checkbox to skip the version checks. In all honesty, I'm not even using the version number. It was just a harmless command to see if the module was installed. If it comes back with anything, I'm assuming things are good to go.

[DavesCodeMusings]

I just published version 1.20.17 with a checkbox configuration option called Mpremote › Startup Check: Skip. This will skip over running python --version and python -m mpremote --version when the extension loads and hopefully do better with virtual envs.

[erikdelange]

Great, works perfectly! Thanks for solving this small but annoying issue.