Add stub location summary at completion

[andrewleech]

As a first-time user of the tool I had no idea where the outputs were actually generated - took me a while to realise they went into the repos/micropython-stubs directory.

This MR displays a summary showing where stubs were generated after successful completion.

Shows both raw stub paths and merged stub paths for each board processed, making it easier for users to find the generated files.

[Josverl]

Thanks,

I had been thinking to ask you about your experience and if there were any (other) points that would make it simpler for others to contribute stubs.

Any other observations or things to improve?

[codecov[bot]]

Codecov Report

:x: Patch coverage is 9.09091% with 10 lines in your changes missing coverage. Please review. :white_check_mark: Project coverage is 79.04%. Comparing base (145cfab) to head (e84e370). :warning: Report is 18 commits behind head on main.

Files with missing lines	Patch %	Lines
src/stubber/bulk/mcu_stubber.py	9.09%	10 Missing :warning:

:x: Your patch status has failed because the patch coverage (9.09%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #702      +/-   ##
==========================================
- Coverage   79.11%   79.04%   -0.08%     
==========================================
  Files          70       70              
  Lines        6656     6666      +10     
  Branches     1111     1113       +2     
==========================================
+ Hits         5266     5269       +3     
- Misses       1031     1039       +8     
+ Partials      359      358       -1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[andrewleech]

Any other observations or things to improve?

Yeah a colleague and I had some difficulties getting it to all work, I'll speak to him too.

I've got a few other local changes, trying to piece together what's useful and what's a dodgy workaround.

I think there were 3 other main problems:

• Custom build has no lib folder and it's not on the path.
  • Not all ports have lib created by default
• Using with WSL and USB forwarding (typical workflow for me) has longer delays after reset; stubber startup would get stuck in a loop resetting and not waiting enough before retry. I think stubs timeouts / detecting loops could be adjusted.
• User C module lvgl locking up the scan

It also took me a while to figure out the repos folder structure and again a while before I figured out I should generate docstubs and frozen stubs beforehand. But too be fair I barely skimmed the docs, I didn't read anything properly.

Maybe a simplified example walkthrough for generating a full set of stubs for a particular board would be good.

These could have been written in a new issue... I'll try to remember to copy them and/or raise some PR's but all least I've got them written down for now!

[Josverl]

Thanks useful feedback.

• Assuming you ran stubber mcu the lib folder should get created and added to the path, I trust your report - so something is off.
• WSL - I have always ran this in ether native Windows or Native Ubuntu - and there is some slowned in re-attaching after a reset ( not blaming USB manager ) - so yes - that is something that could be detected and timeouts extended
• LVGL - it takes a looooooong time , at least it did when I last ran it a few years ago, it is a huge module to and enumeration takes a long time. Probably should exclude it by default.

Maybe a simplified example walkthrough for generating a full set of stubs for a particular board would be good.

yes, and probably on Windows , and Win + WSL2 ( that should also cover Ubuntu )

These could have been written in a new issue... I'll try to remember to copy them and/or raise some PR's but all least I've got them written down for now!

I checked with management , they are not worried at all :-)

[andrewleech]

• Assuming you ran stubber mcu the lib folder should get created and added to the path, I trust your report - so something is off.

Ah, I think the issue here was directly reported by mpremote mip install ... I think it was the one complaining about missing lib and/or lib on path. Perhaps there's an ordering issue to handle lib before mpremote mip is used?

It looks like sys.path setup is currently in run_createstubs() but mip_install is called earlier in generate_board_stubs()

I also had an issue with trying to run stubber from source while hacking my way around these things like automatic lib handling, the mip install of pkg_full.json pulls the on-target code directly from github so local changes weren't included. Was just a bit of a gotcha, maybe an alternate json file / cli-flag to install from local source would be helpful for development?

[Josverl]

Updated to use the table format.

[Josverl]

merged in a86e7913585947b1c8e792cbf9c595e4de8ed732