My hope (and personal goal) for #CircuitPython2023 is to improve the #CircuitPython development experience, particularly for users. I've especially been interested in creating tools for intermediate users, as the entry/beginner experience for CircuitPython is already phenomenal - so much so that (at least in my own case) afterwards they start looking for more advanced opportunities. In 2022, I created build-mpy for allowing users to create .mpy files for their projects using GitHub Actions. I also personally created circlink as a way to develop and test user code for microcontrollers from a local repository on the computer. Additionally, moving much of the existing CI in the libraries to shared composite actions means both that there's often less patching to do when upgrades happen, and that both Adafruit and Community bundles get these improvements passively, with no opt-in required.
In 2023, I'd love to see these tools mature, as well as new similar tools within the realm of GitHub actions, command line tools, and other features that make developing code as a user better. Some of these include:
- I want to explore bringing
circlink, which currently only works on Unix systems, over to Windows. It's great for myself since I use Manjaro for development, but not having it available in Windows is likely a huge detriment for many users who would otherwise use it. Unfortunately, this may require a reimplementation in another language, or at least utilizing another one along with Python. - I started and aim to complete another command line tool circfirm for downloading the CircuitPython firmware to boards. If I remember correctly, where I last left off, it work really well when the board is in bootloader mode, but needs more work and consideration for how to handle determining the firmware for RP2040-based boards, where the exact firmware cannot be determined from bootloader mode alone.
- I'd love to see more CI improvements for the libraries across all the bundles and related tools. I'm looking to make checks performed by Adabot, our robot friend who help Adafruit online, faster and less prone to getting rate limited due to GitHub API calls. With over 300 libraries in the Adafruit Bundle to date, finding a way to help this scale with additional libraries would be great for futureproofing.
- I'd love to see an issue template for libraries. I think there's a number of issues submitted that would be answered faster and more confidently if there is always a minimum amount of information available from the start, like minimum reproducible code and version of CircuitPython firmware. The core does this extremely well, and I'd love to see it in the libraries as well.
And, if I could make an extended wishlist:
- I'd love to see modules like
warningsandenumin CircuitPython.warningsmake communicating potential issues like deprecation actionable (as opposed to just using print statements to simply display)- Many classes already implement their own version of
enum.Enum, so having a single implementation to be used across them all would make usage much simpler than having multiple implementation being used at once.
- I would LOVE to find a way to propogate library CI changes to users or repositories in the Community Bundle. Whenever bugfixes happen to the CI in the Adafruit Bundle libraries that are applicable to all libraries made using the cookiecutter, there's no way to communicate this effectively and the knowledge has to be transmitted a few time over a great length of time. I honestly don't know what this would look like, but it would allow maintainers of community libraries to focus more on code and less on infrastructure, especially when there's already a known fix or improvement.