Developing in VS Code using mpremote mount option - Read only when running script?

[jerrens]

I have recently started working with MicroPython with a W5500_EVB-Pico dev board (Raspberry Pico RP2040 + WIZNET W5500 Ethernet). I've tried the Thonny IDE as recommended, but I've been spoiled by VS Code and the various extensions provided there. I could deal with Thonny if my project were limited to one py file, but the nature of the project I'm working on will be much easier to manage if I were to split it into multiple files. I also like to keep my code in a git repo.

It seems Thonny is designed to either edit the py files on the Pico (I have to transfer the files back so I can update my git repo) or on the local computer (I have to transfer each file updated over to the Pico to test)... neither option is ideal IMHO.

I ran across the mpremote utility and the mount option and this looked extremely promising. I could create main.py and my various modules in my local directory, making changes to the source code. These changes could be monitored and committed into my git repo as desired and I could run the command mpremote connect port:COM9 mount . run main.py from my project directory and my code would run on the pico.

There are two problems that I currently have run into that I'm hoping there is an easy solution to that somebody can enlighten me with:

1. Windows Path/Directory Separator
   I've opened an issue for this one (mpremote: Mounting Windows directory with packages in a lib subfolder are not found #9734), but the short version is that files in the lib directory aren't found in the mount since I'm working on a Windows PC and sys.path is only looking in '/lib' and not '\lib'. For now, I work around this by adding import sys; sys.path.insert(2, '\lib') at the beginning of main.py.

2. The Opened Terminal appears to be in Read-only mode
   My project contains a command line interface where I'm reading keyboard input on the virtual COM port via uasyncio.StreamReader(sys.stdin). When starting main.py with the mpremote run option, I am unable to enter any commands. I also struggle to kill the script since it doesn't appear to react to CTRL+C keypresses.

If I manually copy my files to the dev board (in Thonny) and run main.py from that IDE, I can interact with the CLI as expected. If I copy all of the files to the dev board and restart it (main.py auto-started by MicroPython), then connect to the board via a tool like Putty, I can interact with the CLI as expected.
I can also run the command mpremote connect port:COM9 mount . and get to the REPL, then enter the code source = open('main.py').read(); code = compile(source, '<string>', 'exec'); exec(code) to start main.py. Using this method, I can interact with the CLI as expected. The downside is the extra step of pasting or entering that command to start main.py.
For now, I have settled on the command: mpremote connect port:COM9 mount . repl --inject-file main.py. This allows me to press CTRL+K to run main.py.

Does anybody else have a better solution for working in VS Code (on Windows) with MicroPython?

I have tried the Pico-Go-W extension for VS Code, but it had problems connecting to my board (it auto-connected with a Bluetooth device and ignored settings to connect to a specific device - I tried both COM port and the ID). I was able to get it working by changing the COM port number of my device so that it was the first device in line for Pico-Go-W to detect and connect, but there were other problems that I also ran into (but don't remember at the moment). The mpremote mount option seems to be the best solution available to meet my needs at the moment. If I can figure out how to keep the run main.py from being read-only, I'll be a happy camper.

[jimmo]

Windows Path/Directory Separator

I replied to #9734 -- use /remote/lib

I do agree this is a bit awkward... I wonder if this should be automatic (or maybe an option, e.g. mpremote mount --add-lib-path)

The Opened Terminal appears to be in Read-only mode

With mpremote run (or exec/eval) the terminal is read-only (it's designed just to print any output until the script/command finishes).

In this case what you want is possibly

mpremote .... run --no-follow foo.py repl

which will start the script and then immediately switch to repl mode instead.

[jerrens]

I do see that the PC directory is mounted by the Pico under the /remote path. After your suggestion, I changed my fix from sys.path.insert(2, '\lib') to sys.path[2] = 'lib' so that sys.path would become ['', '.frozen', 'lib'] and the lib entry would be treated as a relative path and micropython would handle the directory separator. This worked!

What impact on other systems would this have if the default system path was changed from /lib to just lib? This seems to be a more universal solution.

Thanks for the suggestion of the run --no-follow option - it worked perfectly! I didn't see any options for the run command on https://docs.micropython.org/en/latest/reference/mpremote.html. Is there another page with additional details for all the options, or do I need to dig through the source code?

[jimmo]

What impact on other systems would this have if the default system path was changed from /lib to just lib? This seems to be a more universal solution.

Good question... I think there are good reasons either way. Keeping it as an absolute path would result in less surprises, but I agree for this particular use case it would be handy to be relative. In almost all other cases where you have custom filesystem stuff going on it would be more explicit (i.e. your boot.py would have been mounting the filesystems) and so modifying sys.path would be normal.

I didn't see any options for the run command...

We need to add this to the docs. I think you can see it in mpremote run --help but yes overall the docs need more examples of common scenarios and use cases (as well as just explicit listing all the args) -- I think there are a lot of things you can do with mpremote by combining commands together that aren't obvious even if you know all the commands and args.

[jerrens]

Good question... I think there are good reasons either way. Keeping it as an absolute path would result in less surprises, but I agree for this particular use case it would be handy to be relative. In almost all other cases where you have custom filesystem stuff going on it would be more explicit (i.e. your boot.py would have been mounting the filesystems) and so modifying sys.path would be normal.

In my experience in other languages/OSes, the search for imports/includes/requires normally follows the order of 1:

1. Relative to application/script directory
2. Relative to current directory
3. Then a 'system' directory

So a local copies would override global/system copies. I recognize there are arguments about security implications from this approach though.

If I'm understanding the default entries of sys.path (['', '.frozen', '/lib']), it looks like the order is:

1. Built-in
2. Frozen
3. 'lib' folder in the root directory (System Lib)

This approach completely ignore any local copies. As @jimmo stated, normally this wouldn't be a problem since most users would be placing their main.py script into the root directory. The difference is that the mpremote ... mount . utility changes my current working directory over to /remote instead of / that boot.py normally does.

Is there perhaps an option with mount that would allow the mount to occur at / (root)?
If not, maybe instead of overwriting the /lib entry to force it to be relative, my modification would be safer if I were to insert lib (relative path) before the /lib entry. By keeping the /lib entry in sys.path, the change from normal behavior would be less for others who may place shared packages there.