Replies: 3 comments 16 replies
-
|
I may have misunderstood, but judging by the image having the stubs folders marked as source root, I got the impression that the proposed solution entails uploading stubs directly onto the device filesystem. If that is the case, I would avoid doing so. Microcontrollers are by definitions working with restricted resources, and any amount of free storage space is valuable, this is especially true for some ESP8266 devices. If I have indeed misunderstood or if there is a way to do what you propose without uploading stubs on the device file system, then I believe that this is actually the best practice - involving the user in selecting the stub device type. There are a few edge case scenarios to handle that come to mind. The plugin probably should allow the user to somehow manually select/search for the specific device type, if for whatever reason the detection fails or the user has some kind of alternative intent. This could be handled together with manually selecting one's own local stubs. Aside from uploading stubs directly onto the device, which might just be my misunderstanding, this solution seems like the best way to handle stubs in this plugin. |
Beta Was this translation helpful? Give feedback.
-
To me using the mark directory functionality for determining what gets uploaded to my device quite intuitive. The project I work on has two folders marked as source folders to make things more readable and organized, and with how the plugin treats them their contents get uploaded to the device file system without the containing folders, allowing me to organize both the Project and File System layout more freely. If there was just a single pre-generated folder that would be meant to store all files and folders that are meant to be uploaded, it would give users less freedom as far as organizing their projects go. Maybe it's sufficient to only exclude files like |
Beta Was this translation helpful? Give feedback.
-
|
Excluded folder can't contain any stubs. The folder is completely ignored, and the language engine just ignores it. Having several source folders is totally fine. |
Beta Was this translation helpful? Give feedback.
-
I understand now. What you propose makes sense, I can't think of a better way to handle this. |
Beta Was this translation helpful? Give feedback.
-
|
Formalized in #338 |
Beta Was this translation helpful? Give feedback.
-
I had an idea for adding more upload options while testing the pre-alpha 12 release. Currently you have the option to "Upload File/Directory to MP device". Well, for directories you could have more options such as upload entire file/upload contents. I can, however, see how this might be overcomplicating things with how the current uploading priority system with source folders works. I just thought I'd leave this here as an idea in case it could be useful to you somehow. |
Beta Was this translation helpful? Give feedback.
-
|
There is an alternative approach to auto-detection compared to the old one. I personally go back and forth between multiple ESP32 devices and USB ports when working with MicroPython. Different USB hub at work, different USB hub at home and even switching to a different USB port on my computer changes the device path of the Microcontroller I am working with. Perhaps a different form of auto-detection could be implemented in the new plugin. It would make things a tad bit easier if there was a way to track one device even after it pops up under a different device path. Known devices could be saved as device presets, or just the last connected device could be remembered and searched for in the available device paths. It doesn't really matter how complex the functionality built around this device tracking would be. Something like this could theoretically even be used to narrow down the USB serial port selection drop-down list to just devices that can somehow be verified as having MicroPython installed. Now implementing this is where things can get more difficult. Telling apart devices which have MicroPython installed is possible. The unique ID can be used and relied upon on most if not all device types. So some combination of the USB VID:PID and unique ID could be used. I can, however, see how scanning all serial port paths might not be practical. I will leave the question of whether or not this is plausible up to you, you are better suited to answer it than me. But talking about autodetect approach this is what comes to mind for me. If this would indeed be possible and wouldn't require a terribly overcomplicated solution, then some really cool features could be built around it. |
Beta Was this translation helpful? Give feedback.
-
At home it can be 2-3, and at work it is similar most of the time, max could be 5, but that is very rare. |
Beta Was this translation helpful? Give feedback.
-
|
I have reports of users having in excess 32 serial ports connected in their setup and have needed to adapt mpflash for that. It is possible to interrogate the micropython port/boart/variant and version of connected devices , but it does interrupt any running code. |
Beta Was this translation helpful? Give feedback.
-
|
That's a lot... |
Beta Was this translation helpful? Give feedback.
-
|
This is the MicroPython code that mpflash uses to get the info. Tested from v1.9.3 ... v1.23.0 |
Beta Was this translation helpful? Give feedback.
-
|
I'd rather use mpflash as is. |
Beta Was this translation helpful? Give feedback.
-
|
If there are plans to take this approach ,
I have a preference for MIT, mostly to avoid carrying too many different license types into the micropython repo. If that is not possible, then most likely I'll go back to the the somewhat older version from https://github.com/hlovatt/PyBoardTypeshed instead. But before that we need to discuss that with the MicroPython core team as well. Also see: Josverl/micropython-stubs#762 |
Beta Was this translation helpful? Give feedback.
-
|
Oh, you are very welcome to the discussion! And I a have a feature request for you - list available stubs somehow. Either by loading the list from some known url or by calling mpremote with a special key. |
Beta Was this translation helpful? Give feedback.
-
|
These ones have @Overloads defined, which i did not yet add, What do you need for a list of stubs ? |
Beta Was this translation helpful? Give feedback.
-
something like or it might be
The license holder is JetBrains, so we need to ask our lawyers first |
Beta Was this translation helpful? Give feedback.
-
|
Understood, I'm also not a lawyer
For the stub identification / mpflash suggestion
[
{
"serialport": "COM14",
"connected": true,
"family": "micropython",
"description": "Generic ESP32 module with ESP32",
"version": "1.23.0",
"port": "esp32",
"board": "ESP32_GENERIC",
"cpu": "ESP32",
"arch": "xtensawin",
"mpy": "v6.3",
"build": "",
"location": "1-6.1",
"stub-package": "micropython-esp32-stubs==1.23.0.*",
"toml": {}
}
]Would that work , or would you also want an option to get a list of all published stubs ? |
Beta Was this translation helpful? Give feedback.
-
The problem:
There are numerous Micropython boards nowadays, and a number of Micropython forks. There is a number of additional libraries to be installed.
As a result, now it's virtually impossible to maintain a comprehensive set of python stubs inside the plugin. Additionally, that diversity of boards makes board detection by USB VID:PID useless in many cases.
Proposed solution
os.uname()pipinto the project structureAs the result, a typical project layout with `main.py` and compiled `ssd1306` library would look like:
Device layout looks like
Any thoughts or concerns?
Related to #220, #240, #141, #114, #326, #319, #316, and many others
Beta Was this translation helpful? Give feedback.
All reactions