Is there a way to determine the version of the installed pimoroni_pico MicroPython variant? If that is not possible, I request to support such a feature. That way an IDE like my ‘eric-ide’ (https://eric-ide.python-projects.org) could check the installed and the one available on Github and potentially inform the user about the availability of an update.
The best I have is:
os.uname() // print(os.uname())
In Thonny, on my Windows PC I get the following:
MicroPython 699477d on 2023-01-16; Pimoroni Pico LiPo 16MB with RP2040
Type "help()" for more information.
>>> import os
>>> os.uname() // print(os.uname())
(sysname='rp2', nodename='rp2', release='1.19.1', version='699477d on 2023-01-16 (GNU 9.2.1 MinSizeRel)', machine='Pimoroni Pico LiPo 16MB with RP2040')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported types for __floordiv__: 'tuple', 'NoneType'
Sorry @alphanumeric !! – I should have been more clear. My apologies.
The “//” is an or otion - as it in the following:
OR IN THE OS of DEVICE:
Unfortunately os.uname() doesn’t contain the version of the Pimoroni Pico library. I would expect a ‘v1.19.12’ or something like that.
Not to worry, I had a bunch of things (distractions) happening around me. I just did a quick clip and past, and post, before heading out the door on errands.
You can make a reasonable guess from the build date in the
version information there (in the example above, 2023-01-16 lines up with the release date of v1.19.12) but that is … suboptimal for sure.
My code checks the tag of the latest release available on Github (doing a head request to ‘latest’). That means, I don’t have the date information of the release available. Having the version info somewhere in the .uf2 image would be the preferred solution. That could even be a text file containing the data (like CircuitPython boot_out.txt).
Alternatively sys.implementation() should return the Pimoroni version number in the ‘version’ field instead of the MicroPython version.
Surely pulling the latest from git is (virtually) always going to be running ahead of actual releases?
I mean you could probably work around it buy pulling release data and parsing that but yeah, it’s clunky and would make more sense to be available in the firmware itself.
I wouldn’t be a fan of a text file (because that could easily get disconnected from the actual firmware); this probably makes more sense as an issue though.
I just raised an issue on Github.