mpremote mip install can create a folder named `:`
Port, board and/or hardware
ESP32 , but can be any
MicroPython version
mpremote v1.27.0
Reproduction
PS D:\mypython\mp_wcwidth> mpremote --version
mpremote 1.27.0
PS D:\mypython\mp_wcwidth> mpremote mip install --target : github:josverl/mp_wcwidth/demo.py
Install github:josverl/mp_wcwidth/demo.py
Downloading github:josverl/mp_wcwidth/demo.py to :
Installing: :/demo.py
Done
PS D:\mypython\mp_wcwidth> mpremote tree
tree :
:/
└── :
└── demo.py
Expected behaviour
Expected that :
- the : prefix for "remote" would not be used as the path
- the demo.py file would be created in the cwd of the MCU
- nu folder named
:would be created
Observed behaviour
PS D:\mypython\mp_wcwidth> mpremote tree
tree :
:/
└── :
└── demo.py
Additional Information
Similar issues with specifying '--target :.'
tree :
:/
├── :
│ └── demo.py
├── :.
│ └── demo.py
└── demo.py
Code of Conduct
Yes, I agree
tools/mpremote: Add mip download and mpy version handling.
<!-- Thanks for submitting a Pull Request! We appreciate you spending the
time to improve MicroPython. Please provide enough information so that
others can review your Pull Request.
Before submitting, please read:
https://github.com/micropython/micropython/blob/master/CODEOFCONDUCT.md
https://github.com/micropython/micropython/wiki/ContributorGuidelines
Please check any CI failures that appear after your Pull Request is opened.
-->
Summary
Adds a new sub-command for mpremote mip: mpremote mip download, inspired by pip download, which accept same packages and uses same logic as mip install, but downloads files to local filesystem instead of remote micropython board.
Fixes #18711.
A use case: run mip download for all the dependencies, and add ./lib to python.analysis.extraPaths or whatever your ide/setup uses -- and now you have a proper code completion and go to definition working with same code obtained by same command as the code running on the board.
An issue on Raspberry Pi forums by someone else on this with more details: https://forums.raspberrypi.com/viewtopic.php?t=377948
Testing
- tested that mip install maintains old behaviour with no changes.
- tested that mip download works without a connected device, but also works with connected devices when
--mpyis set to download mpy files.
Trade-offs and Alternatives
An alternative approach is to only keep mip install command and support both local and remote paths in the --target argument.
I have considered this alternative to adding mip download command and keeping mip install, but I have decided against it due to following reasons:
Backwards incompatibility in path handling
Many mpremote commands already support working with both local and remote filesystems, and : is used to reference remote filesystem.
The mip install doesn't follow that convention: it can only work with remote paths, so mip install's --target argument treats all paths as remote, and doesn't support the : notation for remote paths.
Making mip install follow this convention would be a backwards incompatible change which I wanted to avoid.
Defaults for mpy argument
The mip install prefers mpy files instead of py files as those are a better default for files installed to the micropython environment.
However, preferring mpy files to py files for locally downloaded files is not a sane default: the mpy files won't help for most use-cases where local downloads of mip packages are needed.
Having multiple different commands makes the mpy defaulting easier: it makes more sense to have different defaults for different commands rather than to have the default value for a flag change depending what was provided in the other flag.
pip download command
There's a pip download command the mip download command matches, while the pip install arguably doesn't provide options to just download the packages to a given directory. This makes the mip download command be recognizable for people already familiar with pip commands.