 Hello everyone! This is CircuitPython Weekly for Monday, October 30th, 2023, one day before Halloween. This is the time of the week where we get together to talk about all things CircuitPython. I'm Liz, and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support Adafruit and CircuitPython, consider purchasing hardware at adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.it slash discord. We hold the meeting in the CircuitPython dev text channel and the CircuitPython voice channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with a U.S. holiday. In the note stock, there's a link to a calendar you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you would like to receive these notifications, ask us to add you to the CircuitPython NISA's Discord roll. There is a notes document to accompany the meeting and recording. The final notes document includes timestamps to go along with the video so you can use the dock to skip around and view the parts of the video that interest you most. The meeting tends to run 45 to 60 minutes. After each meeting, we post a link for the next meeting's notes document to the CircuitPython dev channel on the Adafruit Discord. Check the PIN's messages to find the latest note stock so you can add your notes for the following meeting. If you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. This meeting is held in five parts. First part is community news. This look at all things CircuitPython and Python on hardware. In the community, it's a chosen set of items from our Python on Microcontrollers newsletter. Second part is state of CircuitPython libraries and Blinka. This is a quantitative overview of the entire project. It's a chance to look at the project by the numbers separate from our status updates. Third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking time to recognize the awesome folks in our community. Fourth part is status updates. Status updates is an opportunity to report on what we've been up to. Take a couple of minutes and talk about what we've been doing in the last week, since last meeting and what you'll be up to over the next week. And the fifth part is in the weeds. In the weeds is an opportunity for more long-form discussions. These discussions can come out of status updates or be something you've identified a head time as too long for status updates. And that covers how the meeting will go. And with that, we'll get started with community news. And big headline CircuitPython 9.0 alpha 2 and alpha release for 9.0 has been released. Version 9 adds significant capabilities over version 8, 80 fruit blog and release notes are available. Noble changes merge updates from MicroPython v 1.19 all the way up to 1.21. Expressive update to IDF v 5.1 and a few other things noted there. Personally, I can just say I've been running the 9.0 alpha on a matrix portal S3 and it's been going well. Another headline CircuitPython Blinka compatibility layer is now supporting Raspberry Pi 5. CircuitPython programs for Raspberry Pi and other single board computers running Python. Raspberry Pi 5 support added with the new compatible version of lib GPIOD. I know Melissa also did some speed testing with that too. And then project of the week, a QR code menu printer. I'll, I've seen it around. I haven't been sure how to pronounce it. It's a portable combination scanner printer for converting QR code menus into physical copies is running on CircuitPython. Very cool project if you haven't seen it around. That was by Guy Dupont. And then this and more is available in our weekly Python for microcontrollers newsletter which goes out via email on Monday morning. So that was today. Visit adafurdaily.com to subscribe to the newsletter. Thanks to Ann for putting the newsletter together. If you have any Python on hardware projects to share or find content you'd like to see included, please consider contributing to newsletter. You can have a PR on GitHub, mention Ann underscore engineer on Twitter and hashtag CircuitPython or email cpnews at adafruit.com with a link and for folks on Macedon, those are also Apple Bull. And then that is community news. Next up is the state of CircuitPython libraries and Blinka. This is a quantitative overview of the entire project. It gives us a chance to look at the health of the project separate from our status updates. We'll talk about the project overall then separately discuss the core libraries and Blinka. First of all, for overall we have 34 pull requests merged by 19 authors. There were six reviewers, 84 closed issues by 11 people and 21 opened by 18 people. And assigned Hacktoberfest label is zero issues, but I believe the entire project is Hacktoberfest Apple Cool. So next for the core, Scott, would you like to read the core? Sure. Let me just find my tab. Okay. So for the core, we had 25 pull requests merged from 13 different authors, lots of new folks, lots of folks in general. Some new names, Dan Zhu is new, Pedro Mencano, Misano, Snip I are all relatively new names to me. We have three reviewers, Jeff Dan and myself. And we have 19 open pull requests, which is well below our 25 single page goal, I would say. So that's good. But a lot of these are the same. So as always, let's take a look at those if we can and try to get the older ones closed for sure. Issues wise, we had 74 closed issues by six people and 12 opened by nine people. So that's what 62 closed. I know that the vast majority of those are due to Dan's going over the long-term issues, which is super awesome. So thanks to Dan for that and all of the people involved in the issues. We currently have 671 open issues, which is obviously down from the 700 plus that we had. Thanks again, Dan. We have eight active milestones. This is how we triage and prioritize the work that Adafruit funded folks work on. If you're not Adafruit funded and find something in long-term, for example, feel free to do it. We're still happy to support you doing that stuff. It just means that Adafruit folks may not do it anytime soon. So we have 15 open issues on 8.2x, which is our current stable release. And we have 60 open issues on 9.0, which are the things that we want to get fixed or looked at before the 9.0 stable release. And we now have 9xx open issue as well, which is stuff we could do once 9.0 is stable. So that's sooner rather than later, but not before 9.0. And then we also have a 10.0 milestone with no issues. This is where any breaking changes tend to go right now, because we're just into, like, don't forget to do this in 10 mode. We have two issues, not a sign of milestone that need to be triaged. That was when these numbers are, that will have changed a little bit. But generally, we're keeping up with the issues and triaging them as they come in. That's it for the core. Awesome. Thank you. And next, we'll hear from Tim for the libraries. Yeah, thanks, Liz. For the CERC Python libraries this week, this covers all of the projects that are on GitHub under the name AdafruitPythonUnderscore, and then a library name will come after that. This is the Python layer of code that allows you to interact with various bits of hardware or provides helper functionalities to make things easier to do, typically higher level inside your code. Across all of those libraries this week, we had seven pull requests merged by five authors and five reviewers. For our authors, I don't think we have anybody who's brand new, but maybe the less frequent folks, thanks to Cedar Grove and Veladak, as well as to you, Liz. I've seen you've been getting involved in library development and reviewing, so that's really cool. Thank you for that. In terms of reviewers, we had our five reviewers, relatively usual folks, I think, that are doing reviews this week. Of those merged pull requests, the seven that we had, they were pretty much all on the newer side. The oldest one was only 10 days old, and the newest ones were a handful that were only one day old. That leaves us, I should say, with 43 open pull requests now, the oldest of which is 431 days, and the newest is just one day. There were six closed issues in the past seven days by six people with seven new issues opened up by seven people. We don't have issues signed Hacktoberfest, but all of the repositories are, so all issues in PRs do count for that. That leaves us right now with 666 open issues, right in time for Halloween. We have 19 of those are labeled good first issues, and you can find those 19 as well as all the rest of the issues at circuitpython.org slash contributing. On that page, it will list out the open pull requests as well as issues across all of the libraries. There is a dropdown that you can use to filter those issues in particular by different labels that are applied to them, including the good first issue label, which is a great place to go. If you are looking to get involved in Circuit Python, you want to help contribute or test or things of that nature. That's a good place to get going with that, as well as joining us here on the Discord. On the PyPy side of the stats this week, we had 168,124 PyPy downloads for all of those 316 libraries combined. The top 10 list is here in the note stock if you'd like to take a look at it. I think to my eye, the ones that look newer in the top 10 that I don't think we see there typically are the, I think those are accelerometers, some kind of drivers in there. That's interesting to see. There is also a list here in the notes of the libraries that were updated in the last seven days, including one in the community bundle, as well as a handful in the Adafruit bundle. Take a look at those in the note stock if you'd like. That's what we've got for libraries this week. Thanks. Excellent. Thank you. Next, we will hear about Blinka from Melissa. I don't know. Let's see here. I lost my window. I found it. Okay. So Blinka is our CirclePython compatibility layer for MicroPython, RaspberryPy, and other single word computers. And this week, we had two pull requests merged by two authors, myself, and I'm not sure you pronounce it spelled A-N-H-M-I-U-H-V, and then two reviewers. There are currently three pull requests amongst other repositories, and there were four closed issues by one person and two open by two people. And we have 76 open issues remaining. There were 15,747 Pi PI downloads last week, 8,799 Pi Wheels downloads last month, and we are now up to 125 ports. And that's it. Excellent. Thank you. And that is the state of CirclePython, the libraries, and Blinka. Next up is Huggerports. Huggerports is a chance to highlight folks in the CirclePython community and beyond for doing awesome things. I will start and then we'll go down the list alphabetically to give everyone a chance to participate. If you are a text only or missing the meeting, I'll read your notes when I get to them in the list. So I will start. I'm going to kick things off with a group hug. And then I'll be reading for Cedar Grove to FOMI guy for digging into the CirclePdependency scheme for community bundle libraries that reference other community bundle libraries and ADCC for continuing to apply exceptional insight into addressing a Mac OS Sonoma fix. And now we'll hear from Dan. Okay. Thanks for maker Melissa who helped out figure out what was wrong with some broken library builds on Sunday and other broken builds. Thanks to FOMI guy Tim for reviewing and releasing some updates I made to CircleP on Sunday, which was great because CircleP was broken at that point. Thanks to Jeff for some changes that he's working on to bring us closer to MicroPython and he's working on these even while he's on vacation. He's doing it in spare time. So thank you. Thanks to Deshipoo for a quick fix for 9.00. There are some problems with module properties for keypad specifically but it points out a general problem that we need to audit a bunch of things about module types, about native module types. And thanks to Scott for fixing some remaining issues with the MicroPython merge and adding the warnings module which is going to be really handy in the future. Okay. Okay. Awesome. Thanks Dan. Next we'll hear from Deshipoo. Deshipoo, I don't think we heard you, but you had a group hug. So now I will read for DJ Devin who's text only. Todd Bot for expanding his QDI iBall code to the Qualia RGB 666 boards and displays. Retired wizard for the shout out and helping get Todd Bot's QDI code working on their hack tablet. To me for beautiful earth and Mars demo on the Qualia four inch round display posted on mastodon and for expanding matrix score board with even more capabilities. Thank you. Tanute for the Friday deep dive on features and changes coming on the horizon. FOMI guy for a Saturday morning deep dive into circup and web workflow. And C Grover for all his work on the chimes and midi libraries. And now we'll hear from ADCC. Thank you, Liz. I'd like to send a big thanks out to Dan H for always being available with helpful advice and information. Thanks again, buddy. Thank you. And now we'll hear from FOMI guy. All right. Thanks, Liz. Echoing the the last one. My first thanks for Dan as well for finding and pulling a specific old version of Nina firmware from a pipe portal as well as another one to Dan for looking into the issues that were that were causing circup to crash and submitting a fix that fixes those and makes it more resilient to failed bundle downloads. I have a report to Vladec for submitting the PR in circup to allow it to work with the web workflow. So devices that don't connect as USB storage can use circup with this new functionality, which is really cool. Thanks to Scott for continuing the display evolution and splitting out the various different display types into separate modules. Thank you to maker Melissa for working on the pi five support in Blinka. That's really cool to see. And then my last one is outside of circupython land. But I wanted to just say thanks to sneak and John Hammond, who's a YouTuber. They put on a 24 hour fetch the flag event last Friday. It was the first time I participated in capture the flag event and it was really fun. There were lots of interesting puzzles and I learned several nifty tips and tricks from solving the ones that I actually managed to do. And that's what I've got for now. Thanks. Awesome. Thank you. And now we'll hear from Katny. All right. First up, I have a hug to Paul Cutler for a lovely chat and some great ideas to Dan for keeping me in mind with regards to some science updates to you Liz and Noah for a great informative chat to Melissa for some excellent regular chats and a group hug for everyone. Thank you. Apologies if anyone heard some background noise. My cat just demolished some stuff. Next we'll hear from maker Melissa. Hello. I wanted to give a hug to Dan for helping out with the an issue causing library builds to fail. To Katny for some great chats, to Ann for a quick review of the Circle Python boards and a group hug to everyone else. Excellent. Thank you. And now we'll hear from Michael Pacuska, who's text only. So I will read Dan for explaining an issue of GitHub builds connected to Python 3x being changed from 311 to 312 and to Jeppler for adding support for repel.py that I suggested some time ago during a meeting. I somehow missed that it got merged and learned only a few days ago from the Adafruit blog. And now we'll hear from Scott. Hello, Liz. Thanks for iterating with me on the new Circle Python library guys that you've been working on. Hug to Dan for a lot of things, but first leading three Micro Python merge efforts, going through all the long-term issues and fixing lots of stuff over the weekend. And last up, thanks to Dishupu for fixing the keypad property stuff that I missed. I'll have to figure out why I missed that. Excellent. Thank you. And thank you for helping me out with the learning the CP library API stuff. All right. And that was Stas updates. Next up is in the weeds. Oh, no, I'm so sorry. That was hug reports. Next up is Stas updates. I had scrolled down too far. So Stas updates is our time to tell folks what we're up to individually. I will start and we'll go through the list alphabetically. When I call on you, take a couple of minutes, talk about what we've been doing since the last meeting and what you'll be doing until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on if the discussion becomes too long for Stas updates, we can move it to in the weeds. And with that, I will get started. So I've started working on a space clock project with the 720 by 720 round display, the four inch one that's in the shop with the qualia board. Projects could display coordinated Mars time, MTC and Earth time in the time zone of your choice, but with an analog clock face. So you'll be able to switch between viewing Mars time and Earth time. Right now I'm in kind of the beginning phases of the project, researching how MTC is calculated, making sure the images look good on the display and figuring out how the math will be involved for having the clock hands move to correct positions. And next I'll read for C Grover. After building a custom PCM550101A I2S DAC breakout for a stereo line output, I've been looking into how to use it to send your XCV control voltage signals from SynthIO such as LFO and ADSR envelope waveforms. The I2S DAC is DC coupled as capable of outputting frequencies of well less than one hertz, including DC voltages from negative three to plus three volts. It's looking like a new SynthIO CV object will be needed, expecting that the new object could be made to be compatible with traditional analog DAC and audio PWM IO outputs as well. Sounds very cool. And now we'll hear from Dan. Okay, hold on. So I released CircuitPython 900Alpha2 last Friday. That's the first alpha in 900 that has a real release. We know of some things that we want to fix right away, so we'll probably have an alpha three really soon. As mentioned, I reviewed all 600 of the long term issues and closed about 50 of them and asked a few people about a few other ones. And so that cut down the long term issues by about 8% and refreshed my memory of all those. And it took like three hours or so to do that. There were a lot of build problems over the weekend because GitHub Continuous Integration started having Python 3.12 as the default version of Python and there are enough incompatibilities that it caused a bunch of things to break. So we pinned some things to 311. The uf2conv.py utility needs to be updated because it assumes something that is not true anymore in 3.12. And there's also some stuff about setup tools that's not true anymore in 3.12. And this caused a bunch of things to break. And Melissa and I fixed these that worked out okay. I also updated SIRCUP so it doesn't break so quickly when the bundles are messed up. If the bundles are missing or something, SIRCUP used to just give up and now it will, if you upgrade to the latest version of SIRCUP, it will try really hard to use something that it's already downloaded or download what it can. So go ahead and update SIRCUP. So that's pretty much it. There were a whole bunch of connected bugs which was like a, there were a cascade of things. And every time I went down one path, I found something else that was broken. So, but I think it's all okay for now. And we need to eventually make things work with Python 3.12 properly. Okay. Awesome. Thanks, Dan. And thanks for all your work on all of that. Next we'll hear from Deshipu. Okay. I think I fixed the mic. Okay. Thank you. So unfortunately, I gave up on the touch version of the keypad. I simply don't have the experience with C and with microcontrollers to pull that off. Sorry. I tried different things, but it doesn't really work the way I was hoping. Maybe someone else can try it. I'm still looking into the speech module from the MicroPython on the MicroBeat. That's basically from Commodore 64. And it works on the MicroBeat. So there is no reason why it shouldn't work on circuit Python. I just have to figure out how to connect it internally. I will probably just generate a buffer and that you will fit into audio IO without having it run in the background because that's too complicated. Yeah. And I had some successes. I finally managed to add touchpad to my circuit Python keyboard. So I have a nice pointing device built into it. And because Halloween is coming, I gave a free body to one of my robots and with so many ears in there. So that was a fun project as well. That's it. Thank you. Awesome. Thank you. And love to see your robots dressed up. So next I will read for DJ Devin. Purchase two, Kuala is P32 S3 boards and four inch round RGB 666 displays modified Todd bot's QDI code to work within a couple hours. There are pros and cons to the 720 by 720 display. Bad thing is there's a lot of pixels to draw. So the performance ceiling for FPS is much lower than say the two inch RGB 666 display. The display itself has a gorgeous image quality that looks perfect for canvas and automotive gauges with vector graphics. There are many new possibilities to be explored with the RGB 666 displays, but the sheer size of the larger displays will require performance concessions for most projects. And next we'll hear from ADCC. Thank you, Liz. All right. So I got pulled back into the Mac OS Sonoma issue, but that's a good thing. We've had some new useful information that indicates that if the file system is larger than 8 megabytes, it works around the problem. So now the issue is trying to find a way to fake up a greater than 8 megabyte file system to satisfy Sonoma. Along the way, I found the root cause of a longstanding issue where Circuit Python was not able to mount on Android. Turns out that Circuit Python reports a fake MBR with a partition code that Android does not support. Simply changing that code allows Android to mount Circuit Python, and that includes FAT 12 file systems. Before a poll, we're going to need to test this on a number of OSes to make sure that changing that code doesn't cause anyone else to break. And finally, I've had no progress on the Bluetooth support for Raspberry Pi Pico W this week. And that's it. Back to you. All right. Thank you. And next we'll hear from FOMI guy. All right. Thank you. So last week, I did a lot of testing around various versions of Nenafirmware. I also did for the first time figure out how to build the Nenafirmware. Mostly, I was trying to find a specific version that can work with the Cleveland Art API, which is from a LearnGuide project from a while ago for PyPortals. I believed there was one version that I had seen work, and so I was going through trying to find them. And with Dan's help, I did eventually narrow down which one it was. It was potentially the one that came preloaded on the device, although I'm not super certain of that, but we did eventually track one down and we're able to get it to work with that other version. So at some point, we'll try to figure out what the differences could be and if there is some way to update the newer versions to get them to work as well. While I was doing testing on that, a different issue exposed itself in the same project, an issue with the bitmap label, was occurring where sometimes it would crash because it was trying to blit pixels inside of a bitmap to some out-of-bounds ranges. I think it's based on the specific font that's used and then which position the characters appear in. There was one of these issues that popped up that I found a pretty easy fix for and submitted that and that solved it in some of the cases, but it turns out there must be some more of those cases caused by different triggers because those crashes are still happening. I'm working now. I have it running on my PyPortal here and I keep clicking it every time it's done loading to try to find one that causes it to break so that I can then go back into bitmap label and fix whatever the next out-of-bounds issue is inside there. It'll be much easier once I have some text that actually causes it. That's kind of where I'm at on the Cleveland Art Front and then the other stuff that I worked on over the past weekend is digging into CIRCUP a little bit. I wasn't super familiar with it so I was trying to wrap my head around how it works inside there and what the various components are within it to make it go. I wanted to do some testing on the Web Workflow support which was submitted in a PR and I did manage to get that working on a couple of my devices. That's really cool. Then the other thing that I was wanting to learn about CIRCUP for is to figure out a solution for library dependencies that are outside of PyPy. CIRCUP right now handles dependencies automatically from requirements.txt and it converts from the PyPy name to the CIRCUP name automatically but if you have a dependency that is in a library bundle but not published to PyPy we don't really have a specific place or way to do that today. I've been looking for what's the easiest way, what's the best way for us to provide that functionality for dependencies that are not in PyPy but are in a bundle. That's what I have been up to. Thanks. Awesome. Thank you. Now we'll hear from Katni. Hello. I have not been up to much CIRCUP Python stuff but since I was last here I've been building up and wiring up my office into a workshop recording studio. I've been going non-stop and everything is really coming together. I'm super close to being ready to start documenting projects and builds and sharing content. I'm really excited about reaching this point. It was a lot of work but it's been entirely worth it. In a bit of a sneak peek one of the things I did was put acoustic panels on my door which doesn't sound like a lot but it turned into a pretty big ordeal. Sound carries really badly in this house so it was definitely a necessity but it took two tries and I made a lot of notes on what I did and kept track of what worked and what didn't and this is the first project that I'm going to document and share and that's what I've got. Awesome. Thank you. Good to hear from you Katni. Next we'll hear from maker Melissa. Let's see. Last week I finished up writing the CIRCUP Python driver for the CST 826 capacitive touch driver which is the capacitive touch chip on the 2.1 inch RAM display. I did a speed comparison between the GPIO and GPIO 0 on the Raspberry Pi 5 and wrote up a playground note about it and I have a link to it in the documents. I added a the 4 inch RAM display to the Qualia ESP32 S3 guide. I added a bunch of new boards to CIRCUPPython.org. There was like 19 new boards for CIRCUP Python and three more for Blinka. Or maybe it's actually four for Blinka. I added a RAM mapped out with fixing an issue with causing that was causing library to fail when building because as Dan had mentioned they had bumped up to 3.12 if you just specified Python 3 and the GAP actions. This week I'm working on writing the Arduino driver for the CST 826 touch screen and then I'll probably do guide updates and continue to try to find some solutions for the board meshes and that's it. Awesome. Thanks Melissa and now we'll hear from Scott. Hello. I merged in the display IO split so it will now and I also added a warnings module modeled after Cpython's warnings so if you do like import display IO dot display it will print out a warning which will give you a heads up that in the future and 10.0 will be removing it. The warnings module allows you to turn that off which is why I added it so take a look at that and give me feedback if you think it's actually well it's not helpful now in my opinion because 8 is still out there and we can't it doesn't have the split but let me know what you think about having those warnings and how hard it is to turn them off that sort of thing. In similar news I added a friendly error for dot show so this is nice and relevant because you can change it immediately and it just tells you how to change it. It tells you to use root group it does not work whereas with just the display IO split the old way of doing it still does work. It just also prints out a warning. You can also set it to raise an exception so if you see warnings and you actually want to figure out where there are you can actually set them to do an error instead which is really handy. I merged in 8.27 into main to get some fixes into main in 9.0. I also fixed neopixels in main and that should also be out and those are both in alpha 2 I think and I did a couple cleanups after the 120 merge. I am picking up the split heap work and we'll finish it this week and it'll go out in the next alpha or two. The idea with this is that we always have a heap outside of the circuit python VM and this is really useful for any allocations that we need to do that will live longer than the VM and will potentially be passed into other libraries like protomatter as well. So it's looking really good but it is going to change the behavior of GC mem free so be aware of that and it's possible that the projects that are on the cusp of running out of memory will work differently. So I'm really curious to get feedback about how well this is this ends up working for folks. I was going into this work with the hope that we could remove the limitation on how many displays are required but I think I'm going to punt on that for now. This work is really handy for things we know we need outside of the VM but displays and like I squared C and spy buses are used for displays and it's not clear how to handle the case where like you may or may not need it after the VM. So I'm just going to punt on that in the in the short term and we'll iterate on the split heap stuff as 9.0 matures and that's it for me. Great thanks Scott. And with that was status updates. Next up we're going to go to in the weeds. In the weeds is an opportunity for long form discussions that come either come out of status updates or the folks have identified ahead of time. If you have any in the weeds topics please make sure they get added while we're discussing other things so we're not waiting around see if anyone has topics. However today there is a cornucopia of topics. So first we'll hear from foamy guy and he writes would it be good to add circuit pr slash issues circuit python dot org slash contributing page or perhaps piped in via the discord bot like the core and a few other repositories are. I think currently these don't show up anywhere outside of the standard GitHub notifications which makes them a little easier to fall through the cracks and Dan adds I would like to add circup and a few build tool or pause forage to the circuit python dev notifications. This is easy and I'll do it after the meeting if there's agreement works for me. I was going to say sounds good to me as well. I forgot to unmute myself there for a minute thanks Liz. No problem. All right I will do it. Okay great like circup and maybe ate a bot and there's some other similar repose circuit python build tools that kind of thing. Okay all right next I will read for DJ Devin. The new qualia displays currently require the init sequence to be included in code.py which is a departure from the way most displays work in circuit python. I'm assuming it's because there's no driver library yet. Will there be an RGB 666 driver library with a display import in the future? I feel like maybe Melissa can speak to that. Or Scott? I think it's a good idea. You know the way that we've handled it is we usually do display initialization on a per chip basis but in this case it might be more relevant to do it on a per display basis. I know that we have this we have this in the learn guide but yeah I think it is probably wiser to just put it as a driver library. So yeah I think it's a good idea. I don't know who's going to do it but I think it's a good idea. Yeah that makes sense where we can just kind of like say init the 2.1 round display and it could have all the init sequences built into the library like a python library. Yeah it kind of seems like it's do you think it's probably okay being one library and not one for each? Correct yeah it's more of a convenience library kind of like the feather wing library was. Yeah of course me. Melissa are you willing to do that? Yeah I can do that. Thank you. Cool all right next one is also from foamy guy. All right this one is for a patch from I started working this couple of weeks back there's a prn8 about for it this patch was to fix the docs being able to build specifically inside of read the docs like they build locally fine but they needed this tweak because they changed some of the way that their infrastructure worked. It was approved but I don't have access to merge it I just wanted to check in and see if anybody else wanted to look at it before it could be merged and then see if there was any preference on the timing to run it and then I noticed the other issues popping up over the weekend about the github actions change changing their environment as well and I'm guessing that there will be another change in the libraries to support that so the next thought that I had was would we want to do both of those patches together and then just do one release afterwards that has both of those changes or do we want to just stick to like one thing at a time change one release and then change the other and release or is it the case that we don't actually need to change the libraries for that action steal that could be as well I would not super positive on it. I think given that you mostly work on Mondays I think Mondays are good days to do it. They're also good in the sense that like the folks that work all week will be around to clean up anything that has an impact as well so generally like earlier in the week is better for for doing stuff that might have consequences. I don't think you need two releases but I think you probably do want one just so that like your diffs are clean kind of throughout throughout for other changes if that makes sense. With both patches so like do the patch that's in and then once we make a patch for the version of Python kind of apply those both and then do the one release after. Yeah yeah and if there's too much time between them you can always just do two releases that's fine too. But there's often like a backlog of changes that turns into a release so if those things are separated patching versus releasing I would just do it in this in a single release. Okay cool. I will um I'll poke around with the libraries a little bit it sounds like it's just a matter of changing inside action so I'll work on like a draft PR and we can hash out anything there that needs to be different and then get a patch spun up from that one as well. Thanks. And next we have Dan. So my because of the troubles with bundles over the weekend it's still the case that the circuit python org bundle which is not the community bundle is missing a 9x bundle and in fact it hasn't had any libraries added to it since 2021. So I'm just wondering I think the idea of this was that there would be libraries that were maintained by the hypothetical circuit python org organization as opposed to being uh maintained by individuals by contributing individuals but there are only like two or three libraries in there right now so should we consider getting rid of this bundle or copying what's in it into the into the community bundle and if we don't do those things does anybody just know how I can trigger a bundle release without forcing I think I may have to make a without forcing like without updating one of the libraries that's already in the bundle so any any thoughts about this third bundle which isn't even mentioned in a bunch of places it's not mentioned for instance I think in circuit python org and I like the theory of it I think it might be as simple as actually just making a release on github to get it to make a new one right so like usually adabot will update you know check to see if any updates need to be applied and then make a release but I don't think there's any reason you couldn't just make another release you know following the same format even though all the versions will be the same but that will force the build and the release artifacts to be built I think okay I thought it was the other way I thought that there was something in adabot that scanned all the libraries to see if they were changed and then did a release yeah it does it does do that but I'm saying you could manually make another release and then all the artifacts get built based on that trigger oh okay okay all right I hope so I'm not sure but I'll see I think it may put in the source code release but I'm not sure yeah I don't know what gets triggered but also I mean people don't know about this this this bundle so that's what I'm talking about I mean is it supported in circup yes that's what it is yes it is supported in circup are people using it through there yeah it's like circup circup was breaking because there was no nine x bundle so I fixed circup so it wouldn't break but now every time you run it it will now try to download it and complain that there is no such thing so so that's why I want to you know at least get a bundle and then maybe consider do we really want this I mean it could be in the community bundle and it could just be that there are some libraries in there that are assigned as community supported as opposed to individuals supported or something yeah or community bundle but still live in circuit python orc kind of keeps the delineation but moves it into the other bundle yeah I was I was just going to mention I think a lot of the libraries in there originally were some display stuff and there were a couple of folks working in a larger team on some of them but there are fewer these days so it is I would say I'm fine with them either way moving or staying going to the community bundle or staying in that one and I will also offer up if you do have trouble getting it to build I'm willing to poke around on that as well so if you give it a try it doesn't work and you want to have somebody else look into it I'd be happy to do that sure thank you and I think it may be it may be possible to make a build I forget what it's called some kind of build action manually triggered build actions and we can add something to ate a bot or something to do that right now I've been like just rerunning existing jobs which works some of the time so you could it looks like if you just made a manual release it will it will build everything great and I will do I will make a manual release and change the numbering scheme okay yeah yeah just like I would just follow what you know the like date the date they right right right you could like do yesterday's date just to make sure yeah I'll try that okay I'll try that right now all right yeah it looks it looks like it's set up for GitHub actions to come along and do the zipping and stuff for you after okay all right I'll try that thanks all right thanks folks so some good discussions and with that I'm going to wrap up this has been the circuit python weekly for Monday October 30th 2023 thank you to everyone who participated if you want to support Adafruit and circuit python and those of us that work on circuit python consider purchasing from the Adafruit shop at Adafruit.com the video of this meeting will be released on youtube at youtube.com slash Adafruit and the podcast will be available on major podcast services it will also be featured in the python for microcontrollers newsletter visit AdafruitDaily.com to subscribe the next meeting will be held next Monday as usual at 2 p.m eastern 11 a.m pacific this meeting is held on the Adafruit discord where you can join by going to adafruit.it slash discord to be notified about the meeting and any changes to the time or day you can ask to be add to the circuit python needs his role on discord we hope to see you all next week thanks everyone