 Hello and welcome. This is the Circuit Python weekly for June 5, 2023. This is the time of the week where we get together to talk about all things Circuit Python. I'm Scott, and I'm sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit. So if you want to support Adafruit and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to the URL adafru.it-discord. We hold the meeting in the Circuit Python-dev-text channel and the Circuit Python voice channel. This meeting typically happens on Mondays at 2 p.m. Eastern 11 Pacific, except when it coincides with the U.S. holiday. In the notes doc, there's a link to a calendar where you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you'd like to receive these notifications, ask us to add you to the Circuit Pythonista's Discord role. There's a notes document to accompany the meeting and recording. The final notes document includes time stamps to go along with the video, so you can use the doc 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 Circuit Python-dev channel on the Discord. Check the pins messages to find the latest notes doc 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. The first is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a preview of our Python on Microcontrollers newsletter. The second part is the state of the Circuit Python libraries in 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. The third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The 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 you've been doing in the last week since the last meeting and what you'll be up to over the next week. The fifth and final 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 ahead of time as too long for status updates. That covers how the meeting will go. And with that, we'll get started with community news. I'll switch docs here and do community news. So community news is a brief look at all things like micro-python and Python on microcontrollers generally. It is a preview of a newsletter that goes out every Tuesday morning thanks to Ann. So the first thing here is we have notes of a new release to the Python editor, a THANI editor, which provides new features. A new version of the THANI Python editor has been released with bug fixes and new features. The default installation uses Python 3.10 and looks to run in 64-bit mode. ESP flashing dialog now allows selecting from a list of known micro-python and circum-python variants and downloads them for you. This is version 4.1. And you can check out this link to the Twitter post about it as well. Three. Next up, we have PyCon US 23 and PyCastCades 23 videos are out now. The PyCon US 2023 talks are now available on the PyCon US YouTube channel, which is youtube.com slash c slash PyCon US. PyCastCades 23. The PyCastCades 2023 talk recordings are now available on the PyCastCades YouTube channel. And there's a big, long link that I will not read off. But you can check it out in the Discord channel or in the Note Stock or the newsletter that comes out tomorrow. Speaking of YouTube, there's a new micro-python YouTube channel that's official. I just subscribed to myself. And it looks like they have the micro-python meetup videos there, which is awesome. And they're very useful to hear about all the latest and greatest things in micro-python land. And that is youtube.com slash at micro-python official. All right, last up. Software driving hardware. Hackaday was talking about Christopher Barnett's very insightful analysis of what the future holds for the Raspberry Pi single board computers on their podcasts. On the one hand, they're becoming such competent computers that they are beginning to compete with lightweight desktop machines instead of just being a hacker curiosity. On the other hand, especially given the shortage and the increase in price that has come with the pies expanding memory endowments, a lot of people who would just throw in a Raspberry Pi are starting to think more carefully about their options. These days, there is no shortage of microcontrollers that have enough memory, both Flash and RAM, to support a higher level environment like micro-python. If you think about it, micro-python brings to the microcontrollers a lot of what the people were using Raspberry Pi for in projects anyway, a friendly interactive programming environment that was free of the compile here flash there debug cycle. If you're happy coding Python on a single board Linux computer, you'll be more or less happy coding in micro-python or circuit-python on a microcontroller. And that's it for the preview of the Python on Hardware newsletter. The Circuit Python Weekly newsletter is a Circuit Python community-run newsletter emailed every Tuesday morning. The complete archives are available at atifruitdaily.com. slash category slash circuit-python. It highlights the latest Python on Hardware to related news from around the web, including circuit-python, Python, and micro-python developments. To contribute your own news or project, edit next week's draft on GitHub. That's github.com slash atifruit slash circuit-python dash weekly dash newsletter. There's a drafts folder there. Take a look at that. And submit a poll request with the changes. You may also tag a tweet with hashtag circuit-python on Twitter or email cpnews at atifruit.com. 2-2-3-1 puppy, I'm happy to. I can read your question. Thanks for dropping in. I really appreciate it. All right, next up is the state of Circuit Python, the libraries in Blinka. This is a statistical overview of the state of Circuit Python, meant to kind of ground us in objective metrics. These are numbers from the last seven days. We do, if the meeting shift, we do kind of miss things. So sorry if we missed you. But let's get started overall. So overall, we had 17 poll requests merged from 10 different authors. So new names to me are Graham Winter, Tamiahola, Juliana Kulo, Hicks0329, Rockola, and Atlantor already are all somewhat new. Thank you to them, and thank you to our consistent authors as well. We had six reviewers, which is awesome. So thank you to reviewers we support. Well, reviewers support authors, so we really appreciate it. Issues-wise overall, we had 20 closed issues by 13 people and 15 open by 15 people. So we're net down just a few, which is great. OK, for the core, we had four poll requests merged from four different authors. We had two reviewers, and we have 23 currently open poll requests. It looks like most of those are a week old and not a bunch of new stuff, so we'll have to keep an eye on that. And a number of those are graphs, and a lot of those graphs also have to do with boards. So please take a look and see if you can't help move along any of these old PRs. That would be great. But being at 23, we're under my kind of rule of thumb of being under a single page. So issues-wise for the core, we had five closed issues by four people and eight open by eight people, so we are net up three. For a total of 654 open issues, you can check those out all on GitHub. We have seven active milestones. Milestones are used to know what we've triaged and set prioritization for those of us that are funded by Adafruit to work on Circuit Python. We have one open issue for 8.2, which I opened and has to do with the CPX library not working on the CPX anymore. Seems kind of like a bad thing. We have 37 open issues for 8.xx. And these are kind of like things we should do soon, but no concrete plans to do. And then 9.0 are things that we want to do for the next major stable release. We have two issues not assigned to Milestone as of these stats. So we'll have to take a look at those and make sure that they get triaged as well. So that's it for the core. And I'm going to hit it off to Jeff for the library update. Hello. So Catney is up to something else. I assume she is watching the Apple keynote. So I'll read the library section. This, let me get back to the text because I'm not as good at reading this as her. Yeah, so this describes all of the Circuit Python libraries, most of which begin Adafruit underscore CircuitPython underscore, although there are a few outliers that don't. And the last week's activity saw 13 pull requests merged by six authors, including some of those that Scott already mentioned as new or infrequent contributors. We had five reviewers, and thanks to all those reviewers for enabling us to keep the software quality of the libraries high, there is a list of the merged pull requests in the notes document, which I won't read off. Issues-wise, that leaves us with 60 open pull requests, rather, with the oldest nearing 1,000 days, which is maybe a need of some attention, and the newest is one day old. Issues-wise, we saw 12 issues closed by seven people, and seven open by seven people. It's nice to see the range of activity and always fun when we go down a little bit in issue numbers. Of those issues, we've got 50 that are tagged good first issue. And you can review all of this at circuitpython.org, just click the contributing link at the top of the page. You'll find a list of all the open pull requests, open issues, and a list of library infrastructure issues. If you'd like to contribute to circuitpython by writing Python, this is a great place to start. You can sort the issues by label, so you can search for good first issue if you're just getting started, or bug or enhancement if you're looking for something a little more advanced. We have a guide on contributing to get and get hub, and we're always available to help you get started with that, so let us know if you need any assistance. And of course, I mentioned that you can find the open pull requests there. Your informal reviews on pull requests are always welcome, and if you find that you are enjoying consistently doing that, we can level you up and put you on the review team, which among other things will allow your name to appear in the list in this document. So thanks also to everybody who is commenting on pull requests and testing them and is not among the formal ranks of reviewers. All right, I've just got a little bit more statistics. We track how many downloads there are of the libraries from PyPI, and that was over the last seven days, 111,186 PyPI downloads of our 310 libraries, and there's a list of the top 10 libraries by download counts in the Note Stock. Next, we've got libraries updated in the last seven days. There are about four that were updated, which I won't read off, and there is a new library, which is in the community bundle called CircuitPythonDisplayHT16K33 by Jay Puzzata 2020, which I'm not familiar with that display, but I think, is that one of the LED-based displays? So check that out if you are into that sort of thing. And that wraps it up for the libraries. Back to you, Scott. Thank you, Jeff. Okay, next up, I'm gonna read for Blinka. Blinka is the CircuitPython API compatibility layer that sits atop MicroPython and also works on single board computers, such as Raspberry Pi, to provide the CircuitPython API. In Blinka, there were zero pull request marriage. There are three currently open, and they've all, two of them have been open quite a while, so I doubt that they're gonna be in any time soon. PlatformDetect has one currently open that is usually done for adding new single board computer support. Issues-wise, for Blinka, there were three closed issues by three people and zero open by zero people. That's also great. For a total of 94 open issues on Blinka itself. Download stats for Blinka. PiPI downloads in the last week was 11,097. PiWheels downloads in the last month was 7,076, and there are now 119 supported boards. That's it for Blinka, and that's it for this state of CircuitPython Libraries and Blinka. Next up, we have Hug Reports. Hug Reports is a chance for us to say thank you to the folks in our community for doing awesome things. It's done as a round robin, so I will start, and then we'll go down the list of folks who are listed in the node stock, and hopefully in the meeting as well. As always, if you're not able to make the meeting, feel free to drop notes in here, and I will read them off, so you'll hear that too. So for me, let me take another timecode. I just wanted to give a hug to Tac, who does for continued TinyUSB and TinyUF2 support. Just following that and watching all of the different microcontrollers to get support was really fun, so thanks to Tac for taking that on. Next up, we have Dan. Okay, thanks. I'd like to thank Greg Nevaroff. He and I had a very helpful audio discussion about, he has some async.io changes that have been proposed that have been in the pipeline for a while, and now that 8.1.0 is finished, I'm trying to circle back to those. So we had a really good discussion. Okay. Awesome, thank you, Dan. Next up, I have notes from DJ Devin3. Take a timecode. DJ Devin3 says, hug report to Ventrue for helping to turn a hard cut RGB cycle into a nice rainbow fade using PWM. And next up is FoamyGuy. All right, thank you, Scott. Hug reports for me this week first. Thanks to you, Scott, for sharing some insight into some of the bits inside of Core Display.io. Hug report for Jose David, who created the virtual HT16K33 emulator library and shared that in the community bundle. It's a super interesting thing. And lastly for me, thanks to MicroMelissa for some suggestions on the non-blocking marquee functionality inside of the HT16K33 library. Thanks. Thanks, FoamyGuy. Next up is Jeff. Hello again. I wanted to thank Melissa for testing the Matrix Portal S3 board definition and figuring out that we needed to update ProtoMatter. And of course, Philby for advancing ProtoMatter to work better on the S2 and S3 using the LCD peripheral controller. That presents a few issues for the CircuitPython update, but I think it will really make the display on those microcontroller families work a lot better. So it'll be cool to see that come into CircuitPython. And then a big list of people who have been showing off SynthIO. JP, Mark, and Liz were on Show and Tell last week and they all had projects based on it. And Todd Bot has been making some videos about it. And I'll tell you a little bit more about that. How that's going when we get down to my status updates. Awesome. Thank you, Jeff. Next up, I have two more to round us out that are both folks missing the meeting. So I will read them off. First up, Katni's missing the meeting and says hoards to BlitzCityDIY for generating a fritzing object for me for an upcoming guide. Hugs to DNH for a ton of help understanding the wiring behind a breakout board. And last up, we have notes from maker Melissa, who says, how reports to DNH for help with getting my CircuitPython environment functioning. Hugs to Jepler for making the board definition for the new matrix portal and a group hug. That's it for how reports. Next up, we have status updates. Status updates is a chance for you to talk about what you've been working on in the past week and what you plan on working on in the coming week. This is great for collaboration and also just knowing kind of where everyone's at and what they're working on. So I'll start and we'll go through the list just like we did for hug reports. So for me, I added one wire in UART support to the pirate code. This kind of gets me to the point where I think it's good for 1.0. I poked at the STN32G0 for a bit of a pirate break and I'm crashing it now. So I'll probably poke it a little bit for a break today or this week as well. Just trying to get blinky going on it. I did a little bit of MCU flasher work but the Sandy 51 is still pretty unreliable to the point where it feels like it's bricked which is not great. So I don't really feel confident in that code right now. So I'm taking a break from that. That's like really, really deep down into the leads of my grows which is take some grit to do. This week, I think I'll be taking another deeper look at USB host and circuit Python starting with the IMX RT. TAC has done some work since I looked at it last and I need to take a more thorough look at it and see if I can't get it working. Lastly, I got a laser cut chip board that is a grid of 0.1 inch holes with at a two inch, a 0.2 inch spacing. My idea being that I could mount eight of your boards including my imagined synth modules to it but one problem I have is that because it's spaced at 0.2 inches I can't fit anything that's an odd number of tenths of an inch apart. And that includes feathers. So I'm curious to think what, if anybody has any ideas about how I could do this like I could stagger one set of columns to give us an odd number, that sort of thing. Curious if anybody's interested in this. It's kind of my idea is that it's like gonna be your structural backing for putting together like bespoke controllers and stuff like that. Anyway, that's what I'm thinking about and that's what I'm planning on doing this week. Next up, let's hand it over to Dan to hear about what he's up to. Okay, so as I already mentioned, I had a meeting with Greg Nettrall for about ASICIO changes and we'll work on some various things. There's a PR to the core which should not interfere with the current library so he's gonna make sure that's correct and then bring it up to date. And then in terms of the library, the library was just sort of for testing purposes so it probably, you may just close that PR for now and eventually work on like a cleaned up version of that once what he's working on will be moved in. And what he's really working on is trying to make an event loop that is not always polling so that if you're running a bunch of asyncio tasks, then there won't be a loop that's always running in the background, checking to see whether they're okay, things might even go to sleep or in general block on something that would allow less CPU spin. That's what he's working on. Okay, that's the most interesting being the other very minor thing I'm working on but it seems to be taking too much time is that I'd like it so that you can just fetch the submodules for a particular port instead of going to the top level and fetching all the submodules which now takes several minutes because we have so many submodules and I thought this would be really trivial to do and it turns out it's not. One reason is that all the port make files assume that you're building boards but here's a new target that isn't a board build and so that assumption about building a board was wrong and I had to undo a bunch of stuff because of that and also the other thing is that it's just extremely painful to do any kind of programming with if statements and doing computation either in GNU make or in shell. They're both kind of horrible as programming languages. So I've gone through several iterations on this but I think I'm seeing the light at the end of the tunnel right now. And then finally, I would hope to start working on the micro Python, the merge of micro Python version 1.19.1 into main which is a prerequisite or it's something that we're planning for a 9.00 not for any of the A-releases and I hope to start on that this week. Okay. Yeah, noting that once that's merged in that will really turn us into 9.0. Right, I don't think it'll be a draft for a while until we're really done with a or we need to fork. Yeah, we can reach. I think I was talking with Jim a little bit and one two one might be out by the time we wanna get 9.0 out. So it might be that you do 19, Jeff does 20 and I'll do 21. Okay. And I think I asked him and he didn't think 21 would be a different NPY version either. So I guess we could do it as a 9.1 or something. Yeah, I would see that 9.19.1 would be like an alpha which would because we don't wanna have we wanna just have one by the time we get to the beta is we want all the NPY to be stable. Yeah. Yeah, in fact, I may even not do an alpha release until we're on the NPY version number that we know we wanna be on. That might be a good idea, yeah. Well, like we can do S3 builds but not actual alphas until we're on the version we're gonna do just for clarity. Anyway, thanks, thanks, Dan. All right, next up I have notes from DJ Devon 3 who says, making progress on my rechargeable BLE RGB candle. I added a rainbow fade effect battery life hat with a 500 milliamp hour battery is about three days with a 2,000 milliamp hour battery. It's over a week before requiring a recharge. Hacking up the base of an electronic candle with snips is fun and somewhat necessary for beginners. Replicating a 3D printable version to allow for better component placement is the ideal solution. Next up, let's hear from VomiGuy. All right, thank you, Scott. Last week I refactored the non-blocking marquee functionality that I added to HT16K33 library to make it reuse the code better between the blocking version that existed previously and the non-blocking version that now uses some of the same code and we're able to eliminate some repetition inside of there. Which is nice to try to cut the size of the library down some. I also pushed forward a couple typing PRs that had stalled from their original submitting authors. I got a few of those up to the point where they could be completed last week and then I have a couple more that I've been working on this week. I polished up the RGB LED server library that I've been working on. I have now added all of the remaining functionality that I had planned at least although maybe some more stuff will come to mind. And I would say it's nearly ready to make the initial release and get it added to the community bundle. So I hope to do that this week. Over the weekend I did a good chunk of soldering on, I think it was Saturday, I think it was. I soldered up some quad other proto boards as well as a couple feather wings that I had already received but hadn't used yet so they didn't have any pins on them. For this week I will be also jumping back into the core display issue with the hidden elements to try to get that wrapped up. And that is what I have, thanks. Thanks, foamy guy. All right, next up let's hear from Jeff. Hello again, I was just adding my in the weeds topic so let me scroll back up. But last week I implemented bike quad filtering in Synthio and earlier this morning I just moved that out of draft status. There are several other simple kinds of filters that can be created within the same bike quad structure and mathematics that would be useful. Those are called notch, peak, low shelf and high shelf. And I'm gonna leave that as a separate item because I think that would be fairly easy for someone else to contribute. It's mostly math that you copy out of a webpage and just a tiny bit of put this in shared bindings, put this in shared module. So I think that would be feasible for someone else to pick up. Anyway, this week I'm updating Proto Matter which is a requirement for finishing the matrix portal S3 board definition. Since the last time we updated Proto Matter Paint Your Dragon has changed it so that it uses the, I think it's the LCD control peripheral to clock out the data which has some really nice advantages because it's being done by a peripheral instead of a software loop but it needs some structural changes in how circuit Python interacts with it. And as well there are some changes within the Proto Matter library that for instance hit warnings that we have enabled in circuit Python as errors and those needs to be addressed. So that will be a pull request on Proto Matter and in addition to the open pull request on circuit Python. And now I've got a bigger set section for non-circuit Python stuff. I'm working on a guide for the Adafruit learn system that shows how to use the CPM emulator called run CPM on Feather RP2040 board. The code is done but I'm still seeing occasional crashes from the project. I think it's due to the overclocking for the digital video output. I'm also really excited. I use the RP2040 BitBang USB host in this project and it'll be really nice once this is available in circuit Python someday. And then in non-circuit Python, non-Adafruit stuff, I built an EE PROM programmer so that I can update the firmware of my Xerox820. That was a lot of fun. It's really just a bunch of wires and one pull up resistor. I'm so glad I missed the era where you had to use an ultraviolet light to erase your chips. And if you're into this, buy your 2816 eProms now because they're fully obsolete and hard to find. And that's what I'm up to. Jeff, one thing I would request is you should take a look at the EE PROM stuff in bus pirate and see if we can't do it in circuit pirate as well. Oh, I should. Yeah, I wrote a circuit Python code but it's just a circuit Python program. It's not tied in with bus pirate or anything like that. These are parallel eProms, so they have a very large number of pins. There's like, it's a 24 pin chip and 22 of them are data signals, then your voltage and ground. So I don't think it fits within the bus pirate form factor, but there's maybe some way that it could intersect with bus pirate and I'd love to figure that out with you. Yeah, either that or just a library. You could have a circuit Python library then. That's where my brain is. All right, thanks, Jeff. Last up, I have two folks who were missing the meeting, so I'll read those off just like last time. So first up, Katniss missing the meeting. And last week says, put the Feather RP2040 DVI guide into moderation, started the Chalk Neo-Key breakout guide, realized there's no MX Neo-Key breakout guide when I looked for it for cribbing purposes, started updating the Chalk guide, it'd be a Chalk slash MX Neo-Key breakout guide. This week finished up the fixes from Liz's review of the DVI Feather guide, finished updating the existing content of the Neo-Key breakout guide to refer to both types, continuing on the Chalk slash MX Neo-Key breakout guide. And next up is the StemOde gamepad, the TRRS Jack breakout guide, and all of the other things. And lastly, we have notes from maker Melissa who says, last week fixed a couple of issues with the CircuitPython code editor, tested out the new Matrix Portal board that Jeff created. This week, we'll test out Protomatter updates Jeff is making to the core, coming through Matrix Portal and Portal-based libraries to make it more flexible. Need to test PR for the code editor on mobile that will revert a revert I made for the split screen feature. All right, and that's it for status updates. Thank you all. Last up, we have In the Weeds. In the Weeds is a chance for us to have any longer form discussions we want to have. And there's notes from 2231 Puppy that I'll start with and we'll talk about, and then we'll go on to Jeff as well. So if anybody has any other topics you'd like to talk about In the Weeds, please add them as you think of them so that we don't have to wait around at all. Okay, so first up, 2231 Puppy says, could a Docker or Podmon container for Building Circuit Python be of use? Right now, it takes a lot of manual configuration and setup to compile and I'm wondering if that could be simplified. And my personal, I've never liked using Docker. That's what I'll say. They just seem gigantic and they don't really help me out. So I tend to prefer wanting to set it up locally but I also do it really frequently or use it really frequently so I don't have to do the setup a lot. It'd be great if somebody else supported it but I don't know enough about Docker to do it myself. This is something that came up really long ago like Tony who was former Adafruit was doing that but I've never really, I've not gotten it, not grasped it. Any other comments about this? I know Jeff, you've written notes in there. Yeah, I was reading some comments in the document so I'll just jump in with those. The first thing I wanted to say is I'm just unfamiliar with Docker and so I wondered what would it look like to build the software if this was a thing that existed? And then I wondered how much ongoing work is required to maintain these Docker images? So for instance, when we change from one version of ESP IDF to another or one version of GCC to another, what has to happen? How do you ensure that you can go back and build an old version of the circuit Python software? And then the third observation I had is this, we have the information about how to build the software repeated multiple times. We have it as code in the GitHub Actions. We have it as pros in the documentation and the documentation is probably repeated on learn as well as in the core in GitHub and markdown files. And when we do this, can we reuse the Docker to build from within GitHub Actions to substitute for those setup steps? How does this help with reducing the overall cognitive load or is it just creating another thing in addition to GitHub Actions, in addition to the written documentation? Those are the questions that I have about this. And I really sympathize with the difficulty of picking up software and building it and how that can keep away first-time contributors. So if it's an improvement, I'm really open to it as opposed to kind of what Scott was saying. So I think we need to approach it from the point of view of how does it help somebody who wants to be a first-time contributor and think about it from that point of view? So those are my thoughts. Thank you. Dan, do you have thoughts too? I also like, I had to try to learn Docker for unrelated reasons a long time ago and I didn't get very far and it just seemed inconvenient, but it may well be fine. I mean, I'm the one who maintains the building sort of Python guide. I have tried not to put detailed instructions in the repo because they get out of date. I'd rather have only one place to do them. So I just assume not have manual instructions except in a very broad sense in the repo if they're gonna be in the learn guide too. I mean, some people, you know, expert programmers often look in the repo for how to do something. And we have other... So it's sort of like a little bit of a tension between who are we catering toward, but I think the learn guide is okay. I think we could try it. There are people who have offered this in the past, but it's never been completed. So it would be great. It would be nice to be able for people to use all the same version of Git and things like that. A lot of the stuff that's in the learn guide is about exceptions because of very differences between various things. And I also don't know whether Docker would help people who have like, I wanna build this on a Mac and can you use Docker to create a Linux-like environment on a Mac or not? I'm not sure. So that's another open question. So I don't know, but if you have anything to type about this, be interested. I mean, if you're familiar with Docker, then you could make up a straw man kind of example or something, I don't know. Yeah, I think the other thing that I think about is like Microdiv's did some pretty interesting work with leveraging the integration between like the code spaces, right, the online editor in GitHub and GitHub Actions. So it's possible that maybe that's the way, the route that we go. Like if you want it all set up for you, you do the online editor and then just use GitHub Actions to produce your artifacts. But you have to pay money for using code spaces? I think so, yeah. So one comment, because we used Docker at my work to build basically Linux images on Windows is I think there is some advantage there for people jumping in, just from having gone through setting up Windows on Linux, that's a little bit of a journey all on its own, that if you don't wanna take that step, you could run into a barrier. The one caveat to that is your USB handling becomes tricky. I found how to work around that, but it can become a little bit of a barrier when you're trying to transfer things or in the end a lot of times they use putty or me when my Windows side and just mount to drive and copy things over to put new builds on. But if it ever comes to flashing on that, you get kind of lost. Right, that's a guess of problem because the development cycle is not just compiling, it's compiling and then flashing and then maybe even using a J-Link or something. Usually not, but yeah. And yeah, you can use, I did get success running J-Link because it's actually fairly well built in that you can have remote J-Links through IP a lot. And then the newest versions of some of the Windows Linux tie-ins have mounting USB, so I'm not sure if Docker's incorporated those. So there's definitely advantages, but at my workplace, we've got a full-time person handles infrastructure, including the Docker setup. So there is a certain amount of work to maintain it. Yeah, and I don't think any of us other core devs are the people that will do that, unfortunately. So yeah, so 2231, probably if you can come up with an existence proof or something, that would be great. I see their typing. That's a fair point about USB. I wonder if there's a better container solution or something else to make it easier, thanks to the input. Yeah, I mean, I think to some degree, good Docker can get you pretty far because if you use any sort of setup system, then you have to teach people how to use that setup system. That's, I think, where I've always gotten lost with Docker. And then I'm like, why is it taking 50 gigs? Anyway, that's my bias. Okay. But it sounds like Mark could be a really good resource for that as well. Thank you, Mark. Okay, let's move on and let's go to Jeff. All right, well, I was prompted to do this by Scott when we were kind of getting off track during status updates. And I wanted to talk about during the Circuit Python 9 cycle how we're going to handle these changing NPY magic numbers. If I understand right, what we're going to see is one bump during the 219 or one bump when we merge MicroPython 1.19.1 and then a second bump when we merge 1.20 and those are going to be fairly well separated in time and we want to reduce user pain while all this is happening. So here's kind of what I understood and what I made up in my head from what we were talking about. We wouldn't make a formal release like a circuitpython.org release until we think the NPY format is stable and that would be after the 1.20 merge. But we still need to create a get tag so that the Circuit Python version number will reflect that it's a nine, like nine alpha zero rather than being an eight one. And then my totally random thought was that it might be helpful to show the NPY version required somewhere, whether that's in the banner that you see like when you open the REPL or whether it's written into the bootout.txt file. That may not be super important because, well, let me back up a second. Historically, tools like CIRCUP have had to maintain a mapping from like this version number 7.3 uses this bundle version and maybe by putting the NPY version number somewhere like bootout.txt it could simplify this part of CIRCUP so that we could say this is NPY version 23, this is NPY version 25. I don't know what the version numbers are. And then that doesn't have to be maintained in CIRCUP anymore but could be easily seen by anybody who looks at the bootout file including automated software like CIRCUP. And that's my brain dump. I mean, I think that's the numbering that I'm really trying to tie to is the major written number. But like you've hit on like the CIRCUP part with this is that we're gonna do two kind of bumps internally. Well, as I said, like I could make a branch which was the MicroPython merge 9.0 branch and we could not merge that back to mean until it's all done. I don't know if that'd be too confusing or not but I think my main concern with that is that we have a lot of infrastructure for getting builds off main which is really helpful for debugging. Yeah. Right, so being able to go into S3 and pick the different commits and just see if bugs are there would be really nice. So that's kind of what I think why I was thinking, thinking that one thing we could do is we could pull a Microsoft and skip 9.0. Like we could do a nine for when 119s merged in and then with 120 we could go straight to 10. That would confuse everybody, I'm into it. So that's one option is like if we really want to be strict about our major numbers matching up with NPY versions we could do that too. Like numbers are free, like I like to say. So then we would hypothetically have 9.1 be the first stable nine and 9.0 would be the in-between version. No, no, I'm saying 10. It would be 10.0. There would never be a final release of nine. Right, like we would have 9.0 alpha zero just like you're saying but then we would with the 120 merge we just call that 10.0 alpha zero. We can stew about this. So let me see, let me see how much work it is to do the merge and then like we could see like. Yeah, we can decide then. Yeah, yeah, yeah. All right, I guess I'm running the meeting so I should wrap us up. Thank you both for that discussion. All right, let me scroll down in the doc here. Hit wrap up. Thank you all again for, thanks everybody for joining for this Circuit Python weekly for June 5th, 2023. Thank you for all for coming even though there's an Apple keynote that we're competing with. If you wanna support Adafruit and Circuit Python and those of us that work on Circuit Python for Adafruit, consider purchasing from Adafruit Shop at Adafruit.com. The video of this meeting will be released on YouTube at youtube.com.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, let me check my calendar to make sure I'm right, at our normal time next week, June 12th. Jeff is running it at 2PM Eastern 11 Pacific on the Adafruit Discord which you can join by going to the URL adafru.it slash discord. To be notified about the meeting and any changes to the time or day you can ask to be added to the Circuit Python nieces role on Discord. With that, thank you all. We'll have a great week and we'll see you next week. Thank you.