py/modsys: Add sys.implementation._build entry. #16843
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #16843 +/- ##
=======================================
Coverage 98.54% 98.54%
=======================================
Files 169 169
Lines 21864 21864
=======================================
Hits 21545 21545
Misses 319 319 ☔ View full report in Codecov by Sentry. |
|
Code size report: |
|
This looks good to me, nice and simple. I definitely agree it's valuable information to have in a build. |
|
Thanks, works fine
LGTM ! |
Josverl
approved these changes
Mar 3, 2025
projectgus
approved these changes
Mar 4, 2025
hmaerki
added a commit
to octoprobe/octoprobe
that referenced
this pull request
Mar 4, 2025
|
I adapted octoprobe to use this string to termine if the firmware has to be flashed. Worked successfully on all tentacles (TEENSY, ESP32_GENERIC_C3, ESP32_GENERIC_S3, RPI_PICO2_W, RPI_PICO2, LOLIN_C3_MINI, NUCLEO_WB55, ARDUINO_NANO_33_BLE_SENSE, ESP8266_GENERIC-FLASH_512K, ...) Thank you - I love it! |
For a given MicroPython firmware/executable it can be sometimes important to know how it was built, which variant/board configuration it came from. This commit adds a new field `sys.implementation._build` that can help identify the configuration that MicroPython was built with. For now it's either: * <VARIANT> for unix, webassembly and windows ports * <BOARD>-<VARIANT> for microcontroller ports (the variant is optional) In the future additional elements may be added to this string, separated by a hyphen. Resolves issue micropython#16498. Signed-off-by: Damien George <damien@micropython.org>
265d1b2 to
f5b4545
Compare
|
Thanks for the feedback and testing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
For a given MicroPython firmware/executable It can be sometimes important to know how it was built, which variant/board configuration it came from. For example in mpflash and octoprobe; see #16498.
This PR adds a new field
sys.implementation._buildthat can help identify the configuration that MicroPython was built with.For now it's either:
<VARIANT>for unix, webassembly and windows ports<BOARD>-<VARIANT>for microcontroller ports (the variant is optional)In the future additional elements may be added to this string, separated by
-.Testing
Tested on:
_build='standard'_build='pyscript'_build='PYBV10-DP'_build='ESP32_GENERIC'_build='RPI_PICO2-RISCV'Trade-offs and Alternatives
This adds a small amount of code size to most of the builds (except the very minimal ones where it's excluded when
MICROPY_PY_ATTRTUPLEis disabled). These builds have a lot of other features enabled and so should have enough space to add this small feature.Otherwise it's difficult to properly implement something equivalent:
sysentries and probing for features can help to determine the board/build, but it's not an easy thing to do and you need to know for each board/build what properties it has that distinguishes it from other boards/builds (eg forPYBV10-DPyou'd need to probe that it has double-precision float viafloat("1e100")and see if that's infinity or not).