Thank you very much. Hello everyone. I hope you're all staying warm and this silent discuss setting is very interesting. So as you probably already know, like my talk is going to be about driving cultural change to improve software development and CI CD. My name is Roland Heuser. I work for SRI International. I'm a software engineer and just to, so my, the field that I work in is microservices, DevOps, and I work with the SRI Ventures team to transfer technology from our researchers to our ventures and our clients. If you haven't heard about SRI International before, we are a research company in Menlo Park. We've been there for over 70 years. Our main clients are the US government and a lot of commercial clients. We've been around for over 70 years. So this was basically me when I started at SRI three years ago. So like you're ready to go. You want to see all the problems. You want to design solutions for them. You want to implement code. And you may have found yourself in a similar situation where you want to get going. You want to, yeah, you want to like start collaborating and figure things out. So processes and as you start looking left and right, you see more and more people and you see mud going all around you and you may or may not start feeling a little bit stuck in the dirt. So what happened? So in 2017 when I started SRI and some of these things are still true today, but we have a lot of different groups and teams. So we have five divisions and inside each division we have, yeah, five to ten like groups and they all operate very independently. Some of them don't even use our corporate IT services. So like they have their own IT services. They used like different repository systems based on their current needs and depending on if they work on government contracts or if they work on commercial contracts they had different policy and compliance requirements. Many of these tools were in self-service so you either had to reach our corporate help desk or of that particular group their help desk to help you. And one of the challenges for my team that I joined with was we were tasked to work with all of them because we were trying to introduce them to microservices like how to implement them. And so we're like, well, now we have to learn how to interface with 20 different systems and it became a big burden for us. So we felt like this biker or cyclist just like and we see this wall in front of you and we're like, well, I just see problems. Like how can I continue? Like we need a better way to work together. So we knew something had to change but we were a very small team so we didn't have enough backing from management or we didn't have anything that would allow us to make the entire organization change. So spoiler alert, we made it somehow and I'm going to talk about how we did this. So from the status code to now about two and a half thousand projects for we have in our GitLab instance we have a little over 500 people so we have five projects per person. How did we get there? So when I started in 2017, as I said, we needed to find a way for us to work with the other teams. Unfortunately we didn't have a lot of compliance or policies imposed on us so we went ahead and just spun up our little rogue instance of GitLab CE. We started hosting all our projects on it and started pointing, started and told people, well, just go look at our instances as our code and we started collaborating with them in this way. A lot of people got really excited about it and they're like, well, we want to put our projects on there too. So we started adding them by a case by case basis but fairly quickly this case by case turned into a lot of projects. As we grew we realized based on feedback that we needed more capabilities. So we started adding features like more CICD, privileged runners. You may or may not have heard about problems with privileged runners. For SRI, since we have a lot of government work, we want to make sure that if two projects run on a shared runner that they can't modify the host. Docker build, for example, cannot run in a non-privileged system. So we needed to figure out a way how can we do this without running into compliance issues where we accidentally modify our host. One solution for this would be an alternative build system like Canico but back in 2017 it wasn't that well established yet. We later realized that we needed backups. So towards the second half of 2017 we started backing up our system and towards the end of 2017 corporate IT and our Center for Software Engineering that provides a lot of services that we consume internally, approached us and said, so who is running this GitLab CE? We don't know who in the Neater Corporate IT or our IT services are providing it and our team were like, well, we kind of do. And they asked us all these questions, well, so how compliant is it? Can we put ITAR projects on it? And I'm not a citizen so pretty quickly we realized that we needed to change this. Fortunately they didn't tell us to stop. They recognized that there is a huge benefit in using GitLab. So they did a threat assessment. They worked on creating multi-factor authentication using the Git CLI which I haven't seen another tool providing this kind of capability.  In 2018 this was our kind of migration year where we migrated almost all our systems. We also discontinued all of the redundant systems that we had. So that was a big year of like getting rid of licenses that we no longer have to pay. And in 2019 we basically just worked on increasing the usage of our current GitLab instance and even upgrading it. So this is how in just a few minutes how we made this entire migration process. So what helped us transitioning from the status quo to where we are now? I identified six factors that I think we did right that helped us for this migration. And the first one would be leading by example. So we started finding a system that fits the needs that we had and we started using it showing other people how we can be successful. Then the second factor is templates. So we don't just like lead and show off crazy tricks, we also show them how we did it and so that others can learn from how we achieved it. So the others can learn from us how they can achieve what we did. Another important piece is education. So together with the center of software engineering we started setting up like a help desk email specifically for GitLab. We started adding channels to matter most so that they can collaborate or ask questions. We provided hackathons and demos where we used GitLab so more people got exposed to it and saw how it can be used. Our fourth factor is evangelism. So at the beginning when we started using GitLab we didn't expect it would cause such a drastic change but like just the people seeing us using it and getting excited about it kind of snowballed and helped getting GitLab like get corporate IT and everyone else excited about it. So I think evangelism is a very powerful tool that we had. And then oops, I went one step too far. Feedback I think our center for software engineering and all the people that were involved setting up the GitLab instance did a great job at listening to the feedback that people brought to the table. So when people had issues with GitLab runners if they needed help integrating in existing infrastructures and how can we use it with Kubernetes, how can we use it with our artifact delivery system like our people they are very responsive and they set up documentation and they helped everyone to be successful. And then the last piece is compliance. So while our first instance of GitLab was not compliant our current instance makes it very easy to bring compliance with all the restrictions and requirements that we have. We put a lot of energy in automating our compliance process where before you had to send emails to people and they had to add you to a project or even set up the project and they had to ask your manager or other people to get approval so it was a very slow process that could take days. Now with our current compliance process how it works is we can set up the project, add a configuration file and that will be picked up by an automated system that then actually verifies who can have access or not. I'm going to talk about this on this next slide a little bit more because as I just started mentioning compliance can get a little dirty and sometimes it kind of hits you in the face with a lot of dirt. As a government contractor we have to follow like CUI and ITAR restrictions and as a commercial contractor we also have to follow their contract requirements. In one of the things we did is we decided that hosting on premise was the right choice for us so that we have more control. Then what I mentioned earlier is for Git we added a plugin that we can do multi-factor authentication especially for external collaborators on our system. Then the groups for example top-level groups on GitLab are managed by our IT services but self-service is very important so all subgroups are managed our self-service and projects are self-service by default. So whenever I need a project I can just create it and as I mentioned I can add a meta file that says which contracts this project is associated with and then our bot will read this file and decide if that project is one that is access restricted or if it is access unrestricted and if it is restricted how we manage or how we ensure our compliances is that nobody can inside GitLab can add or remove users at that point then we just use an LDAP process where we just use them through our where we add and remove users through LDAP and admin will do those changes. So what is the result? The result of this process is that we have self-service infrastructure. I think this is a very important piece that that we initially didn't have and that we were able to achieve with GitLab so that people can self-provision things like they have to ask permission for everything it takes a lot of energy and time. We greatly facilitated our compliance process. We made it after the fact that I can create the project and then I go through the compliance process and it's also more transparent. I know how these how our compliance process works because I know how the company decides on what information these decisions are being made. We reduced a lot of cost because there is less waiting. There is a lot less communication for us to get repositories set up and configured. The maintainability has greatly improved. Our Center for Software Engineering always tells me that the frequent updates on every 20 second are a blessing and a curse. They always get the latest and greatest features that everyone wants to use and they regularly update the system. We improved collaboration. The takeaway that I hope you take from this talk is that start small with a small instance. Make sure that it works for your environments. Try out all the different settings that you have. Try to delete by example. If you try out everything that you use at your company, you can see what breaks and what doesn't. Make sure you automate your compliance processes or make sure that they have as little friction as possible. We invested a lot of energy in setting up documentation, especially where we deviate from standard documentation that GitLab has. This is what we do differently. You should pay attention to. If you want to know how a merge request works, go look at the standard documentation. If you want to know how pipelines or the YAML configuration works, go to GitLab. I actually went way faster through this presentation than I planned to. I think this would leave some time for questions. You're going around with the microphone. We do have time for questions. Anyone have any? Here we go. I'm particularly interested in more details on the automation you've done, particularly around the ITAR compliance. If you want to have an ITAR or some other sensitive DISTROD project, what kind of things do you do in your compliance process to help that out? That's a good question. I'm trying to think how I can best answer your question. What we do is we have ... I'm going to circle around your question for a second. When we create a new project, we have this meta file that says which contract it is associated to. That will be picked up by our automated system, which then will notify one of our admins that this is a project that has been labeled as ITAR restricted. Then we have a group that will go through the export control if we want non-citizens to work on that particular project or verify who can have access. What then will happen is that they will reach back to the person who created that project and ask who else they want to add to it. Those people will then respond and they will check the restrictions on that project and add them to the LDAP group. I think your question is more around how they ensure the ITAR compliance. Our meta file includes a list of all the people that we add, all the people that we want to have access to. It's basically a YAML file that we customize that the bot will pick up. I think that basically solves that problem. Does that somehow answer your question? Okay. Okay. Just one moment. Congratulations again on the radical transformation. I have two questions. Thanks. Any challenges that you've seen with import? Did you import from native Git or is it from another provider? We had a mix of multiple. We had a lot of different on-premise versions from all the GitLab competitors that you know. We had SVN repositories and we had Mercurial repositories that we had to migrate. We went through all of those. Any specific challenges you would like to give us feedback? I think the biggest challenge we had is that a lot of teams love their autonomy. Why should they migrate to a corporate IT provided service if we can just do it ourselves? Why now do we have to add this meta information to each repository, which is just one file, but there is still a challenge around if you feel like they lost control over their baby. I can understand that, but at the same time, GitLab brings so much more benefits that it's such a small drawback. Great. Thank you. Hey there. So I'm curious, how did you guys go through that migration process of migrating from SVN to GitLab? How did you guys handle that period where you may be working in both environments and dealing with dependencies that may exist in both ecosystems? Yeah, I think in most of the SVN repositories, we were fortunate enough that we could use the migration script that retains the changelog and just migrate those repositories. We still have some huge SVN repositories remaining that we can't migrate at once because they're gigantic. So we have to chop them into pieces, but in general, we were able to just migrate them in one step.


So, hello everyone, this is the Circuit Python Weekly meeting for May 17, 2021. 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 them in Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafru.it-discord. We hold a meeting in the Circuit Python DevCheks channel and the Circuit Python Voice channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the U.S. holiday. If the meeting time has changed, we'll notify you via Discord. If you wish to be notified about the changes to the meeting, we can add you to the at Circuit Python EASIS role on Discord. There's also a calendar available that we try to keep updated if you'd like to subscribe to that. This meeting is recorded. We record the audio from the Voice channel and the video of the text channel. If you'd rather not have your voice recorded, you are still welcome to participate. The video of this meeting will be posted to YouTube and the audio is released as a podcast. If you find this podcast is not available on your favorite podcast service, please let us know. There's a note stock to accompany the meeting and recording. If you wish to participate but can't make it to the meeting, you can leave bug reports and status updates for us in the document and we'll read them off during the meeting. The notes document also contains timestamps to go along with the video so you use the doc to view parts of the video that interest you most. The meeting tends to run 60 to 90 minutes, so this gives you the option to skip around. A link to the notes document is posted in the Circuit Python Dev channel on the Adafruit Discord every week. Check to the pinned messages to find the latest notes doc. This meeting is held in five parts. The first part 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 and microcontrollers newsletter. The second part is the state of Circuit Python libraries in Plinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we're all up to. The third 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 the community. The fourth part is status updates. Status updates is an opportunity to sync up with 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 until the next meeting. The fifth part is in the weeds. It is also the final part. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or be something we've identified ahead of time is too long for status updates. And that community covers how the meeting will go. With that, I will switch over to the note stock and do community news and take a time code. So for community news, first up, upstream micro Python versions merged into circuit Python. Adafruit has recently incorporated updates from micro Python, 1.94-ish through six releases to the latest 115 is nearly three years of changes to micro Python. This brings the Python core used in circuit Python very close to the one in micro Python. It will make it easier to collaborate on the core going forwards. Micro Python's new release policy of one every two months or so should make it easier for circuit Python to keep up to date. We don't share much support specific code, but we're excited to be able to collaborate on the core VM going forwards. Our community has expressed interest in more advanced features of upstream micro Python such as native modules. This merge will make it easier to bring those advancements to circuit Python. And thanks to Jeff, we had a few things highlighted that we gained with this merge as well. One is the assignment expressions sometimes called the wallace operator. It allows you to do like an if test and save something as a variable at the same time. They added variable type annotations as well. And then last up, the matrix multiplication operator. However, this is not yet supported by a micro lab. But now that we're up to date and we're equivalent, a micro lab should be able to support it now, which would be cool. And I think that's the at sign is used for matrix multiplication. Next up, PyCon USA 2021. The official annual Python gathering was May 12th through 15th, 2021. The event was entirely virtual and content is currently available for registered participants. The event talks will be released on the PyCon US YouTube channel approximately a week after the event. Catney is hosting circuit Python development sprints May 17th and 18th. That's today and tomorrow. Be aware that this year is a little different with it being virtual. Stop by the PyCon US sprints 2021 discord and check out the circuit Python discussion channel if you're interested in contributing to circuit Python in a guided setting. There's links to the PyCon announcement and the Adafruit blog. The PyLadies auction team put together a rousing event full of joy and generosity to raise over $11,000. This will benefit women around the world to ensure that the Python community is welcoming to them. Next up, Adafruit Discord reaches 29,000 members. The Adafruit Discord community where we all do our circuit Python development in the open reached over 29,000 humans. Thank you. Adafruit believes Discord offers a unique way for circuit Python folks to connect joined today at adafru.it-discord and see the other Discord milestones on the blog. And a quick early hug report to Mr. certainly who tracks the growth rates and predicts when we're going to hit these milestones so that we can be prepared to celebrate them. Next up, the hunt for a faster Python. Some news around speeding up Python. So the quest for faster Python piston returns to open source. Facebook releases Cinder or should devs just use PyPI at the register. For Python programming, we want to make the language twice as fast as its creator. This is an article about Guido. Guido also talked at PyCon US about faster C Python and Mark Shannon covered implementation plan for speeding up C Python. So if you miss this, Guido moved to Microsoft, works there and Microsoft is funding a team of three Python Cordes with the goal of making Python faster. That's Guido, Mark Shannon and Eric Snow, if I remember right. Next up, a new book on the programming microcontrollers with circuit Python. A-Press has recently published a new book by Armstrong Savero, programming microcontrollers with Python. See a book and a mini review on the Adafruit blog. The circuit Python weekly, oh, and that's it. So as a reminder, the circuit Python weekly newsletter is a circuit Python community run newsletter emailed every Tuesday. The complete archives are available at www.adafruitdaily.com slash category slash circuit Python. It highlights the latest Python on hardware 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. You can go to github.com slash Adafruit slash circuit Python dash weekly dash newsletter, check the drafts folder there for it and submit a poll request. And here's a there's a tutorial link there on how to submit a poll request to add your stuff to it. You may also add a tag a tweet with hashtag circuit Python on Twitter or email cpnews at Adafruit.com and we'll add those two there as well. And thank you to Anne and Catney for working on that. Our second section here we're going to switch to is the state of circuit Python libraries in Blinka. This is an overview of the kind of an objective statistical overview of the health of the project. Then we'll get into the more subjective stuff now and Catney says it's all in now, but Catney did do some revisions earlier this morning. So thank you primarily to Anne, but also Catney. Okay. So for state of circuit Python and libraries in Blinka overall. 66 poll request merged from 28 different authors. This is an increasingly we're up in these numbers in the 60s, which is amazing. So thank you to everybody. Joe Zilla, 86 is a new name. F Harding one is a new name. Blathing is a new name to me. Shibers, Rihanna Don, Code Neal, Razvan, PHP, M Rulillard, Rhein and Rw, R-W-U. Thank you to all of those new folks. We had 17 different reviewers. Thank you to all our reviewers. You were what allow us to have so many authors. So let's keep it up. That's poll request. And then issues wise, we had 36 closed issues by 15 people, 22 open by 12 people. So we're net down 14, which is awesome. So thank you everyone for working on that. Now to the core numbers. We had in the core, 27 poll requests merged from 15 different authors. So thank you to all those authors with eight reviewers. So thank you to those reviewers. We have 19 open poll requests currently. Two of those are older than 200 days. So as always, if you want to help out, this is, I think, kind of the place we need it most right now. If you want to get started in core development, but don't know where to begin picking up one of these older PRs is actually really helpful. Some of them are a bit easy. I think one of these at least is just a board support. So that should be an easy one to pick up a couple of those are a bit tougher, but they do some really cool things. So please check those out. Issues wise in the core, we had 11 closed issues by five people, 10 open by six people. So we're net down one, which is great for a total of 447 open issues. This number does tend to grow a little bit. So we keep track of kind of our priorities within the issues by using milestones to triage. We have zero issues, not assigned to milestone, which is great. And we have 366 open issues under long term. So that gives us an idea of like, how many are there because their ideas that people may want to pick up. But the remainder just under 100. Let's see, we have 61, 7.0 issues and 14 library issues. So generally, reasonably good, I think long term. We don't expect it. We expect that the long term number to grow slowly. But overall, that's that's good overall. What I would say is that we are Dan's been doing some really good work in terms of getting a six, three stable out, which will have new boards. And then seven, oh, we should expect to see and a pre release of that pretty, pretty soon. So keep testing, keep finding bugs and helping us fix those. And we'll get to seven, oh, stable before we know it, I think. So thank you, folks. And with that, let me kick it over to Katni for an update on the libraries. Thanks, Scott. So this applies to all of the Adafruit Circuit Python libraries and a couple extras. So it's every library that begins with Adafruit underscore circuit Python underscore. We had 32 pull requests merged across all of the libraries with 13 authors and 14 reviewers, which is excellent to see. Two of those pull requests were over 70 days old. One of them was 200 days old. So that's really amazing to see those getting picked up, leaving us with 50 open pull requests. We had 22 issues closed by 11 people and 10 open by six people. So we are net down, which is great. Yeah, I did the math right. So that leaves us with 302 open issues. Six of those are labeled good first issues, although I would actually say that that is a dubious list as I've been intimately acquainted with it in the last couple days. And they're not all entirely good first issues. So we need to revisit our use of that label, I think. If you're interested in contributing to Circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find a list of open PRs, a list of open issues and a list of library infrastructure issues, which is at this point mostly internal stuff. You can check out the issues. You can search for them by label, including good first issue. There's also bug or enhancement. And you can check out whether any of those are interest you. If you have the hardware for them, feel free to check that out. Otherwise, take a look at open PRs as well. You can either review it for syntax or stuff like that that doesn't require the hardware. If you have the hardware, feel free to test it and let us know that you did that. And that's a great way to start reviewing. And once you're comfortable there, we can level you up to actually joining our review team. So with that, we had no new libraries in the last seven days. But we did have a number of updated libraries which are listed in the notes doc, and I won't read those off. All of that information is available on circuitpython.org slash libraries as well. I'm really happy to see some of the older PRs being picked up, the older issues as well. Early hug report to Jose Davide for taking on going through all the open PRs. Sneak peek of my status update today. Today and tomorrow I'm hosting Circuit Python Development Sprints. So hopefully we'll see a couple of new contributors on the list next week. That's what I've got. Awesome. Thank you, Katnie. And make room list is here to tell us about Blinka. Hello, for Blinka, we had... Okay, Blinka is our Circuit Python compatibility layer for Raspberry Pi and other single board computers. And it actually is now working on MicroPython too. We had seven pull requests merged this last week by four authors and two reviewers, leaving a... There are three open pull requests still, the oldest one being 211 days. There were three closed issues by three people and two open by two people. And that leaves a net of 52 open issues. There were 9,562 Pi PI downloads in the last week. We are currently supporting 72 boards. The number of issues are going down. MicroPython is now working on Blinka and the Raspberry Pi Pico when running the... Let me repeat that. Blinka and Raspberry Pi Pico running MicroPython was recently added. Right, so it's the Pico running MicroPython and then Blinka on top of it. Yes, cool. Awesome, that's it. Thanks, Melissa. Okay, next up we have Huggerports. This is the first two round Robins. It's a chance for us to say thank you to the folks in our community who've been doing awesome work. I will start and then we'll go through the list of the folks. If something's marked text only or lurking, I will read it off. Yeah, if you're unable to make the meeting, feel free to put notes in there as well. So I'll start and we'll go through the list. So first, I huggerport to Dan H for doing the 6.3x cherry picking. It's kind of daunting to go through all of the changes and pick out the ones to pick. So thanks to Dan for taking that on. Thank you to Damian, DP George, and Jimmo for chatting last week about collaborating between MicroPython a bit more. Thank you to Lukash and Mariatta for organizing the Python language summit also last week. And then last up, I huggerport to Christian from the chat on my live stream on Friday who pointed out that my issue could be a broken neopixel. I was trying and trying and trying to get it to show red and they pointed out that maybe the red element of my neopixel is just broken and that made total sense. So it was really good to get other eyes on that. So thanks to those folks for Christian to pointing it out and everybody who hangs out for my deep dives on Fridays. And with that, we'll kick it over to T.G. Techie. Hi, everyone. Hello. I'm just going to jump right in with a very, very, very big hug to everyone who, this was several weeks ago, commented on my pull request to add a module to Secret Python. And that included Gen-H, Warrior of Wire, and Aerodoc and Deshapoot to name a few. I know many other people did. I think you're included in that list, Scott. And while it wasn't implemented or added, I learned so much. Thank you, thank you, thank you. It was so cool to have all the feedback. The solutions they suggested were beautiful. Okay, I'll get off the soapbox. A hug to FOMIGuy for their dev streams. A hug to everyone working on the upstream MicroPython feature merge. And to the community for always being so awesome. Thank you. Thanks, 2G Techie. All right, a couple of notes here from Anikdata, hug report to Nerodoc and RYang14 for the ESP32S2 HTTP server examples. SeaGrover is just listening. Charles says group hug. And next up is Dan. Okay, what? Wrapping around here. Thanks to Nerodoc who's been working on some issues we've found with macOS on the Mac M1. It's not recognizing serial devices properly. So we're still testing that. Thanks also to Nerodoc who found a safe mode bug in ESP32S2, which is confusing because it made it seem like dynamic USB wasn't working. And thanks to RedM and Deshipoo who made some comments about a PR that I've revived about doing HID boot devices. And thanks to all the other early adopters, very early adopters of a dynamic USB, the pull requests went in and we get a whole bunch of people asking questions, which is great. Thanks to Katni for writing this CircuitPython sprints today at the virtual PyCon 2020, 2021. Thanks very much for that. And thanks to Scott for the heroic job you did of merging in MicroPython and bearing with it for several weeks while we got it all done, it really helps a lot. And it improves our relations with MicroPython. Thanks to Jose David for continuing library work that he's been doing on all kinds of library fixing and canonicalizing and adding examples and stuff. Okay. Thanks, Dan. Next up, we have notes from David Gleub who says, hug report to Jerry N for testing importing my thermal camera with CircuitPython seven and a hug report to Dan H for the dynamic USB descriptor. Next, we have Deharada. So hug report to Scott for helping me with all my documentation question, not just this week, but for a long time. Hug report to Jose David for all the awesome work he's been doing, and then she grew up. Awesome. Thank you, Dylan. Next up, we have texts from Fede too who says, hug report to Tanu for hosting today, thanks. And a hug report to Stargirl for making the first CircuitPython audio company. Let's all help so that there is no need for closing due to parts shortage. Count me in. Weird specific DAC as far as I know. And next up is Foamy Guy. Alrighty, thanks, Scott. First goes out to Laysay Marai-Pourpay for testing a quick fix in a cookie cutter over the weekend. To Jose David for finding and reviewing an old PR for the monster mask that had definitely fallen off my radar, and then just a group hug for everybody else. Thanks, Foamy Guy. Next up is HireFact. Sorry. We can hear you. Okay, I think I just had a group hug this week. Yep, yeah. That's all I put down. Okay, yes, group hug. Awesome, thanks. Next up is Jerry. Jerry, I'll read yours off. And HireFact, you're still unmuted. All right, Jerry says, hug report to David Glaub for the MLX90640 thermal camera examples. Hug report to NaraDoc and Carter for some awesome effort and help channels on Discord. And many others as well, but you both have indeed great fun to watch in action. And hug report to Tanya and all involved in completing the MicroPact on Merches. And next up we have notes from Jay for Sien. Who says, hug report to Katni for cleaning up my rotary seesaw PR and a hug report to Jepbler for writing their rotary IO wrapper class. Next up, we have notes from Jose de Viet, who says, hug report to AnikData for the fun troubleshooting the Color Picker server on Discord. Ah! Sorry, I tried to lean away from the mic to sneeze. Hug report to people that contribute to the libraries. After spending the last three weeks working, there's a lot of work done there that sometimes we take for granted. So a big hug for all of those folks that contribute to the libraries. Hug report to JoeZilla86 for making his first PR in CircuitPython, improving documentation for the Fun House. Ah, Jerry, we can hear you now. Hug report to Les Samurai-Porpe for the help and work on the CARE LCD documentation and working together, reviewing and authoring to make better documentation. Group hug. It's not very present in the chat in real time, but I see the discussion during the live broadcast chat and I see all of the hard work. And last up, a hug report to foam a guy for all the hard work and the graphics library solving, all the little details. And next up is Katni. All right, so first up, I have a hug report for Jose David for taking on going through all the open library PRs to see what can be done there. To Dan H for a lovely chat. To Jeff Epler for a different lovely chat. To Dan H for working on new releases. I have been pointing guides at S3 bucket for downloads. And there's also guides that are just relying on updated board definitions that aren't in any of the releases yet. So I'm really excited to see new releases coming out. To NNJA, Nina for a great talk at PyCon on CircuitPython. And to Terry for her PyCon talk on PyNIT, which is a Python library for altering knitting patterns. That's what I've got. Thanks, Katni. Next up, we have notes from Keith EE who says a hug report to Katni for being so welcoming in the PyCon sprint. And next we have a hug report to Kmatch who says group hug. And next up is Crayola Rose. So a big hug to Katni for organizing and hosting the CircuitPython sprint at PyCon 2021. And a hug to all the amazing people that organized and presented at PyCon 2021. It was an impressive change from last year. So like they really did a great job with virtual. And then a group hug. I miss you all. Thank you, Rose. And last up, we have Maker Melissa. Hello, let's see. I wanted to give a hug report to Katni for reading the Blinken notes last week and hosting the PyCon development sprints this week. And to Jay Posada 2020, which I assume is Jose David for adding an excellent example to fake requests and a group hug to everyone else. Awesome, thank you, Melissa. That is it for hug report. Thank you all for giving those shout outs to the folks that are all of the amazing folks in our community, including yourselves. So next up we have status updates. Status updates is a chance for us to talk about the work that we've been doing in the past week and what we plan on doing in the coming week. It's really good for knowing everything that's going on but also giving tips or tricks or collaborating across tasks if folks are working on or have worked on related things. So that's what status updates is all about. And so I will start and then we'll go around the list like we just did. So 114 and the 115 are merged in. So the MicroPython merge is done. I chatted with Damian and Jim and want to work towards no changes in the PY directory. That's like the core of the core of MicroPython. So there's kind of a smattering of odds and ends that we share there. So we're gonna try to upstream some of that stuff and they're gonna hopefully be prompt with those PRs as well. The status LED change is getting really close. I debug the Sandy issues at the end of last week and need to investigate the M4 can board that I think Jose Divi tested and it didn't work. Also chatted with Trevor and Antonio about the app side of the BLE workflow. My goal is to start on the Circa Python side of it this week. I am getting my second Pfizer shot this afternoon so I may be a little less active at the start of the week depending on how hard it hits me. But I'm very excited and we're already starting to make plans to go visit some folks. So definitely excited to get my second shot. So that's where I'm at. And let's see what's up with TG Techie. Hi everyone. I guess preemptive congrats on the Pfizer shot. So over the past couple weeks I've made a revision to the touch screen watch I've been working on. The board is currently in the assembly and validation phase. If anyone has tips for how to apply solder mask I'd love to hear them. Maybe that's an in the weeds discussion because I have specific issues. Someone I know put an order in for a watch which is a little insane because they don't do any tech. I started making tech, tech talks. Tech talks if you will. And I got my second Pfizer dose yesterday. I haven't had any symptoms yet but I also drank more water than I could measure. I think that helped.  So yeah. Next week I'll be adding or trying to add Bluetooth support to the TG Watch to automatically grab the time from a paired smartphone. So I guess a preemptive hug for the people who worked on the Bluetooth libraries. If I remember correctly, Denich did a lot of the work along with many others. And I'll be starting to alter the next week. Standard library for the TGQI widget set. So it's easier to make it cross-platform. The standard library of widgets is separated from the core implementation. In the fifth version of the GUI could run on the desktop and the watch but this version was rewritten and it's much better but it doesn't have that port yet. So yeah. And that's all. Awesome. Thank you, TG Techie. Thank you. It's good to hear that you weren't hit too hard by the shop. So hopefully I'll be able to do something tomorrow. Best of luck. Next up, we have Dan H. Okay. So as mentioned, I'm working toward a 6.3.0 release. That has a few interesting bug fixes but mostly it has a lot of board additions and updates. So there's a very long list of boards to add and it has the frozen libraries have been updated. I was gonna do a release candidate but we do have a problem. I'll mention it a little bit further down which might delay this a little bit because I'd like to get fixed that before a final. But even that, I might even make a release candidate without that fix just so people can test the boards. As I mentioned, a lot of people are using the new dynamic USB features and we've found some bugs and I had fixed some things and mostly have done a lot of explaining. I started working over the weekend on boot HID support so that you can have boot keyboards and other things that work with BIOS. Boot HID devices assume a standard descriptor like all the boot keyboards are the same so that the BIOS code or whatever doesn't actually have to try to interpret the information from the device, either keyboard or mouse and figure out how it's different from all other keyboards and mice. So however, I'm actually gonna defer putting that in because I have a bunch of higher priority things to do. So the first thing I'll do is that I'm gonna work on immediately is two things, work on a learned guide for dynamic USB because we're getting so many questions and people wanna try it even if we don't even have an alpha out yet. And then the other thing is that we've found that there are some RP2040 boards that don't seem to power up reliably. It's kind of odd. It's really confusing about why this happens. I managed to get a QDPI RP2040 order one last week which exhibits this issue so I will try to do some measurements on it and maybe do some Git bisect on it if that seems like it might help and Lady Aida is also gonna look at that. And it's probably some simple timing problem that we just need to fix. After that, I'll work on finishing the 6.3.0 release and also I'll be working. We'd like to have a key matrix scanner built in. There's already game pad which has a limited amount of help for scanning button pushes but we wanna work on something that has row and column support and maybe a FIFO queue and some other things like that. So I'll be working on that next. If you look at desk of Lady Aida from last night you'll see an example of where this might come in handy. And I'll also be working on a 7.0 alpha release and I'll continue to hunt. There's still a number of bugs that we'd like to fix in 7.0 before we do some as we do work toward a release. Okay, a lot of things. Thanks, Dan. All right, next up we have notes from David Glebe who says, testing 7.0 in the dynamic USB descriptor for Stealth Mouse Jiggler. And next up is Dee Harada. So last week I worked on finishing the Funhouse IoT Hub guide. Should be live sometime soon. I got the Dash Display Library up and running which is my first library so that's cool. And I moved back home from college which is nice because now I can use the microwave without browning out my headphone amp. This week I'm gonna be finishing up the Funhouse IoT Hub guide probably doing a bit more with the Dash Display Library and then working out all the non-guide stuff that's been piling up. Awesome, thank you Dee Harada. Next up is Foamy Guy. Alrighty, for last week I worked on a video in a blog post that talked about the requirement screenshot tool. I made a few of the required changes in the CircuitPython org repos to get them renamed to have org in the name and also spotted a few places to tweak a cookie cutter to help do the future ones. I did some work on the PyPortal screen management server that I've been playing around with and I at least temporarily have decided to start calling it design IO. So that's the name that that will have for now. I worked on user registration and activation and I got the beginnings of a front page so that it's more than just the design page by itself. Also on the CircuitPython org I added the existing repos or maybe I'm saying it the wrong way around but I attached the existing repos to the graphics team so that we can request reviews from the entire team. Previously it was only showing individuals so I figured out how to get that hooked up over the weekend. For this week I'm hoping to get finished up on a couple details on that design IO server and get an instance deployed so that other folks could start using it. I'm gonna look into that fiber map project that you asked me about Scott. I'm going to finish up the changing over the existing org repos and see just try to make sure that there's nothing else we need to do in cookie cutter before making the rest of those. And then the last thing I have on there I'm gonna look into generating HTML instead of image PNG files for the requirement screenshots so that we can hopefully find a way to use something with text embedded for screen readers and stuff like that. So that's what I got, thanks. Thanks for the guy. All right, next up is higher effect. Okay, so this past week I did some kind of miscellaneous bug fixes. I resolved a little minor issue with the Arduino NeoPixels on the ESP32S2 which is not CircuitPython but CircuitPython adjacent because all the stuff is from our NeoPixels module. I merged in the STM32 alarm module which is now available to everybody. I also merged in all of my internal alarm changes which is still in the PR stage. I wrote a bunch of alarm test sketches for various ways that you can use deep sleep on different port platforms in ways that you might want. And I've got some example power profiles for various boards that people could check out if they wanna do low power projects. I caught up on a bunch of the conversations surrounding set next file so I can work on that while being informed of what the work that's been put in to it already. And I took a little bit of time to repair all of my virtual environments because I had a cool conversation with Katni which I should have put in a hug report to Katni for helping me out with pie ENV. Totally forgot about that. Yes, thank you Katni because Polish Moli using Homebrew Python is not a good idea anymore. So I fixed all that. This week I'm gonna be finally wrapping up sleep once for all merging remaining API changes, getting in the RP24, 40 alarm PR and then finishing set next file maybe we'll see. And that's it for me. Awesome, thanks, higher effect. All right, next up we have notes from Jeff. Jeff says, got RGB matrix on the ESP32S2 to be in better shape but there's still a crash during soft reset if Wi-Fi is in use. Micro Python accepted a PR of mine from 2018 after I updated it that speeds up the process of running the tests by automatically running multiple tests in parallel and this week is vacation. So don't expect to see Jeff around. He's traveling and getting away from the computer. So it's great. And I recommend it to everyone. Take vacation if you can. Next up is Jerry. Hi, buddy. I got that. You've got it on the right computer, I think. Can you hear me? Yep. Yeah. Good, good.  I tried it on a Raspberry Pi and 24D Clue in the Funhouse. And so now I've got a nice little setup on a Clue with the battery. So it's portable, good for fun. See if I can find the cats. And there's lots more to learn now about how to use it more effectively but it's a fun little tool. And yeah, I've been continuing on playing with trying to keep up with the 7.0 updates and trying them on as many different boards as I can. So we still like to report my professional job but no anomalies to report. Doesn't mean there are many issues but nothing that needs to be brought up. And then I've been experimenting with the ITC Rotary Encoder. That's been fun. And I ran into the same issue that Jeff raised a note about that they do occasionally, they can drift off of where they're zero. So I'm not quite sure what to do about that yet or where the probability is but how to deal with it effectively. I don't have any ideas. It may be in the seesaw, I'm not sure. So it seems like it must be. Yeah, that would be my guess. Cool, thanks, Jerry. Thanks, Jerry. All right, next up we have notes from Jose David who says, last week open issues, open PRs review and some feature addition to the sensor libraries this week open PRs. In fun fact, temperatures greater than 20 Celsius. So more running and biking and less coding be around but I could be slower to respond. Make it main focus will be in the open PRs and keeping things moving. So please feel free to ask and ping me if help is needed somewhere. Awesome, well enjoy getting outside. Next up is Katni. So excited that the PRs are being gone through. It's dragging up extra work but I'm there for it. All right, so last week added the LED pin to all of the remaining Adafruit Circuit Python boards, updated the welcome to Circuit Python, creating an editing code page to use board.led instead of board.d13 for the little LED blank sketch to make it more widely applicable. For example, to work on Raspberry Pi Pico and now it works with all of the Adafruit Circuit Python boards. So if you run into boards that don't have board.led feel free to violin issuers submit a PR. It's actually a pretty easy fix. Doing it 31 times less simple but one of the time quite easy. Wrote up the guide for the StemaQt iSquared C Rotary Encoder. I don't think that's live yet because we, why isn't it live? There was something I did that, oh I know what it was. We have the project by Dole now and the way we used to do breakout guide pages was we would have, here's an intro. Here's how to install the Circuit Python library. Here's how to install the Python library. Here's how to wire it up and then here's how to use the code. And I needed to sort of like rejigger that a little to get it so that it shows the wiring diagram then it shows how to install the Python library and then instead of having a separate section for the Circuit Python library it explains how to use the project bundle at the beginning of the code section. And I need the more to go through that to make sure that that's what we want it to look like because it's kind of the proto of what breakout guides will look like using the project bundle. So we want to get it right the first time. So that's not live yet, it will be soon. Added pinups images to the RP2040 guides. They're also in the PCB repos. Started the NeoKey Trinky guide in doing that created the template for installing Circuit Python on most boards template which is basically all the boards that just as a double tap reset into enter the bootloader, drag the file, et cetera. I think this might have been a week before last but I updated it today. Wrote a script to identify all the pins on a board that include or the support touch IO including whether a pin requires a pull down at the time the script is run. Which is to say if you have a pull down resistor on the pin it will not show it as requiring a pull down when the script runs. And I did some supporting Hosea.V and going through all the PRs and Friday and Saturday attended PyCon 2021. This week hosting development sprints today and tomorrow feel free to join all our welcome. You are not required to have registered for PyCon and there's a link to the discord which I will link into the chat in a minute here. Finish up the NeoKey Trinky guide starting Wednesday, start the Rotary Trinky guide, work with Dylan to get the CI updates for pilot and black with the pilot and black explanations and the PR templates deployed all the libraries and continue giving all the support that Hosea.V needs to get through all of the open PRs. That's what I'm up to. Awesome, thank you, Katni. All right, next up is Rose. Had to find the unmute button. It hides. Yeah, last weekend earlier I started on a circuit Python project to control my HDMI matrix which is addressable over serial and to switch the USB between the two machines because I have a work machine and I have my personal machine and need to switch between them. And that includes switching the keyboard and mouse and camera. And I've got, I think all the parts now but I need to print a bigger enclosure use or I need to switch to just using a NeoPic, I can't remember the name of the board, the one that's the NeoPixels, the NeoTral SM4. That's the one. And then I made a mouse jiggler out of a NeoTrain key to keep my work computer awake when my personal machine has the keyboard and mouse. And finally got my first Pfizer shot on Friday two weeks before the provincial booking system slot. Now I have to wait four months for the next one. And then this week I'm participating in the first day of circuit Python sprints and Katni has a number of issues in mind for me already. And as part of that, I kind of got distracted and worked on getting a 64 by 64 LED matrix working with a rotating Python logo. And I shared the code to generate the rotation emin or the rotating sprite in Jupyter Notebook that I've linked and also 3D printed a diffuser for it from transparent gray, but the printing could use work or can use to be thicker. Awesome. Thank you, Rose. And last up we have maker Melissa. This last week I finished up a fun house home assistant water sensor guide. I worked on an issue with inner ref util that was causing issues with learn guide PRs to fail. I tested out the SSD 1680 monochrome key display with the driver. That's the new monochrome 2.13 inch that we're transitioning over to. I tweaked some guide code to work with it because it needed just a little bit of adjustment. And I updated the fun house capacitive touch pad code to work a bit better. This week I am testing out an issue with the Raspberry Pi installer script, something to do with rotation. I'm gonna do a sweep of any new boards for circuitpython.org. And I'm gonna start working on a new guide for running Blinka on the Raspberry Pi Pico with MicroPython. And that's it so far. Thank you, Melissa. All right, that's it for how I was gonna say other words, status updates. Thank you to everyone. All sorts of awesome things that folks are working on. And last up we have in the weeds. This is a chance for us to have any sort of longer form discussions that we wanna have. If you have topics, there is one topic to start with but if you have other topics, please add them now. Put your username and then kind of what the topic is and we'll just go through those. So first up, I'm gonna kick it over to Jerry. Yeah, thanks. And it looks like Melissa's answered most of the questions in the text here, but if you want us to go through them, hopefully others are interested too. I was just curious how you actually go about using Blinka on a MicroPython board. I know I tried it in the past without much success and got myself very, very confused. So, and so I was curious as to what the basic steps were to get it going. I don't think there's an actual guide to that. So it sounds like there's gonna be one at some point. So, well, and so Melissa, do you wanna, it looks like you're planning on doing an issue thing that explains it, but go ahead. Yeah, I kind of like went over how I got it working. And on some of the older boards, it may not work very well because of the limited memory on them. But the steps were to copy the platform to text stuff over. The Blinka code over, all of it. And any libraries that you need, like the bus IO library is a common one, I would notice. And anything else you need. And then you name your main script as main.py on there. And that's... Okay, that sounds great. I'll go through that example. So, and then if you wanted to use it on a, you're asking what board to support it. You said it's the supply board and the Pico right now. That I've tested for sure. It's supposed to work on the ESP32 and the ESP8266, but I would guess they probably don't have enough memory at this point because Blinka has grown so much. Yeah, so I had to do a bunch of changes to get it to work on an ESP8266, but in fact, I can't remember where I got it on the ESP, it's on a 66 of the 32, but I got the basic started. But so maybe the changes you've made recently have made that part so that it should be worked out of the box, but I'll try it again. Yeah, that's funny. Okay. But it would be really nice to have it working on the 32, I think there'd be a lot of demand for that, I would expect. Yeah, I mean, if you wanna try that out, but when we were getting it working, we just wanted to kind of set the pie board as the guaranteed one to work on and then I decided to add Raspberry Pi Pico while I was at it since it was a newer one. Yeah, no, that's a great one. And because there's so many people out there, but okay, I'll take another look at the 32s and see if what's gone on has made it more clear as to what I need to do to get it working. That's great. And then the next question I had is, I always find it, somebody asked about Blinka and I have to tell them how to install it. I always have a hard time finding the guide because I always have to remember to search for Raspberry Pi, not, if you search for Blinka, the guide for installing Blinka, the basic guide doesn't come up in the list. But if you search for Raspberry Pi, it comes up as number two or three. So it's- I know I have to like search for weird terms like Raspberry Linux and then it kind of comes up like- That's why it is a way to make it link to that one when someone asks for Blinka. I'm not exactly sure how the Learn Guide chooses their words to search on because it seems to give you really weird results sometimes. If there's something specific that you're looking for, talk to LearnDev. They can do things manually. Okay. Okay. Okay, so yeah, just throw out there as an idea and it looks like you're working on a guide. So that'll be really great to have one of us ready for the other setups, but this will help a lot get started. Thank you. No problem. Awesome. Awesome. Well, thank you everyone. Katnie, do you have anything? I do. At the last moment. Very last second. Yeah, go ahead. All right, so the LED animation library got big and is very popular. Two things I guess I should have seen coming but didn't think about. So the plan is to refactor it and I think I'm probably gonna do this over the next couple of days as I'm hosting the sprints. One suggestion that I think is good came up from Rose who suggested creating basically an LED animation core library, like a library called circuit python LED animation core and factor out all of the core files and a quote unquote core set of animations. The idea being that that library will run on smaller boards because the issue is folks wanna do animations on a trinket and without selectively copying individual animations over, it just, it doesn't fit to begin with. It's not even about importing it. Just the library straight up doesn't fit. So I think that's what I'm gonna do and then circuit python LED animations will remain as it is but it will be only the more complex animations and any new animations and will require the LED animation core library. So I don't know if anybody else has suggestions for this or thoughts on it but that is my plan. I know there's two PRs in right now for two new animations from Mark who already said that they're willing to help move those to another library if possible but if we factor out the core and basically if we refactor it backwards instead of refactoring out the animations instead we refactor out the core stuff those PRs can actually go straight in. So I just wanted to put that out there in case anybody had any thoughts or opinions on something to do with that. Are you saying that like each complicated animation would be its own library? No. Okay. Well, okay, so I'm not really certain because that would be ultra breaking. I'm trying to be slightly less breaking. There would be the core library which has all of the functional stuff, not the animations but the core library would also include like three or four basic animations. The idea being that's what you would run on for example, Trinket. And then there would be a separate library for the complex animations and they would all be in one library. There's separate packages. So in theory you can still copy over individual ones if you really wanted to try and run complex animations on Trinket or whatever. But I don't think it makes sense to actually, and maybe I'm wrong. I guess I shouldn't say I don't think it makes sense. I haven't really thought straight through the idea of factoring every single complex animation into its own module. I haven't, like it's on the table. It's not totally off the table but I'm not sure that's the route I wanna go. I just think, right. I think it's pretty heavyweight to make each right. What I suggested doesn't make so much sense. On the other hand, you don't want people to blindly copy the library. I mean, is this kind of thing of like subdividing a library? Like suppose somebody said, I just want this particular complicated animation and it would fit by itself. Is that just, they need to learn how to extract that. Yes. I mean, could the bundler take care of part of that? I'm gonna say no. Okay. Regarding the bundler. Right. They're like adding a feature to the bundler to reach inside a library and extract only a certain file or something like that. Oh my God. Sorry. So I don't know. Okay. I feel like that's starting to get into sketchy territory, just in the sense that like, how does the bundler know which file to extract? Or how does the bundler know that only that file needs to be extracted? Like that starts to get back into are we telling the bundler which board we're downloading it for? No, I really like, the bundler has the ability to subset libraries and you can give it instructions about. Right. About what do you want from this particular library? Yeah, I don't know. Yeah. So that's the only thing. I mean, that's sort of something to put out there. I think the idea of a core small library for small boards sound great. And that's, I think that solves a lot of problems by itself. I mean, I'm having the same kind of issue. Like the HID library, people want to add other, we only have a US keyboard layout. Right. I would like to add some other ones, but I can't add it to the original library because it would just blow up the CPX frozen library, for instance. Yeah. I have the same issue. And should it be, should those need to be separate library or should they, you know, they could be in examples directory but the examples aren't MPY. It's kind of like, I don't know. Seems like in your case separate modules for each keyboard layout makes sense? It could be separate. Like as in you have like the HID library and then you have like HID French layout. Right, it could be a separate library was what I thought. Yes. Yeah, yeah. That's what I foresaw or what I thought made sense. Right. And so that as though this is the same kind of thing. So. Crows, did you have something you wanted to add? Yeah. We would know what you just started to speak about. Why not do it like you would do it a translation.  If you're gonna, if you want a different keyboard layout under HID. Well, I think that's, people have more, it's not a translate. It's not, it's not at that level. It's at the library Python level. It's not a translation. All right, I didn't understand completely. No, it has to do with there's a module. There's a file called keyboardlayoutus.py in the HID library. And we want a keyboard layout FR and whatever else. But to add those to the library makes it too big. Yeah. That's what I, that's what I was, that's what I thought you meant is to be able to say, okay, I only need the British keyboard. So, Right, so we need the mechanism for saying that. Don't give me all the other keyboard layouts. We do it. That's how it works in Linux. I don't know why you... Yeah.  Like the general idea is to have one core library, right? And then a number of separate libraries that can depend on the original core. And so I think what Catney's talking about for the animations of like, let's split the core out and then that'll be a new repo. And then the existing repo will have all of the existing animations and be compatible, but it will now depend on the core for the core stuff. Great. Yeah, instead of, instead of, instead of, and then that way, if you all you want to do is use animation A. Hi, my... That's animation A, you just call it E. You call it E. Dan, your machine, your machine decided that it didn't like it. It started repeating Charles' words over and over again. It was very odd. And it's not responding to the mouse, so not my info. That was not my intent there. So I missed about the last 30 seconds. So I think, but it's not the same as Translations. I'll just save for right now. So I think we can think about it. Yeah. All right. I think you're on the right track, Catney. I was on it. Okay. Yeah. I will probably do that one next couple of days. And thank you very much. I appreciate it. I appreciate it. Thank you very much. I appreciate it. That's about it. Okay. Awesome. And Rose, should we talk about Stubbs? Sure. Might as well. I actually just tried doing a mixed Stubbs and it ended with a, I think it was a warning, packaging it file, Circa Python Stubbs ended up probably not found or not a regular file. Haven't actually tried to see them if they work, but. Mm-hmm. Because I would love to see this completed. That's why I'm like, excited. You're excited about it. Yeah, it's sort of, yeah, a combination of, I don't know if Blinka would be needed at all, but it would be the Stubbs plus possibly a Blinka Stubbs to give some of the other things needed for, like basically fake devices so that development can be done in a IDE offline and not have all the syntax errors and you could even run Pylint ideally. Right. Yeah, so for folks who were unable to watch the chat, we were having a discussion. Rose was pointing out that Blinka is really helpful for PyCharm and VS Code because it allows for the editors to make some completion stuff. And we've had, we've switched the internal documentation of all of the scene modules in CircuitPython over to Python Stubbs, but there's been a disconnect between that and getting the latest versions pushed to PyPI and then how to make the package, package them correctly so that editors kind of just like, know where to look. So FOMI guys done some work on this too, so thanks to them. And just posted a YouTube link about how to get those loaded into PyCharm. But having it work automatically would be amazing. Yeah. And the usual way I load Stubbs is just to make them install them with PIP-N for similar. Right, that would be ideal. Yeah. Because, yeah. Basically, if I can't install it with PIP-N, if I deem things to be broken. Well, I would agree with that assessment. I think we're so close, like we did all of that work and then Dylan did really good work also getting all the type annotations in those Stubbs as well. So like, it's really under, like we put a lot of work into it. We haven't really gotten all the value out yet, but it would be great too. Yeah, it looks like it's just sort of the last mile needed here. Yeah, 100%. And I think you have the background for it. So that would be amazing if you could get it across the finish line. Yeah, I think the last step is it just needs a proper setup.py. And like the CI automation to automatically release it, but... Yeah, that should be pretty easy these days. Right, yeah. Yeah, so that would be amazing if you pick that up. Okay, another thing for the sprint. Let's make today a long day. Yeah, sorry about that. That's okay. Cool. Well, thank you, Rose. And thanks to everybody who joined us for this Circuit Python Weekly for May 17th, 2021. This has been, I guess I just said what it was. This happens every week at 11 a.m. Pacific, 2 p.m. Eastern on the Adafruit Discord server. If you would like to check that out, please go to adafru.it-discord to join the Adafruit Discord. If you wanna support Adafruit and Circuit Python and those of us who work on Circuit Python for Adafruit, consider purchasing from the Adafruit shop at adafruit.com. The video 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, let me just pull up my calendar to double check. It looks like it will be next Monday. So it will be Monday the 24th at 11 a.m. Pacific, 2 p.m. Eastern. If you wanna be notified about the meeting and any changes to the time or day, you can be asked to be added to the Circuit Python NISAs role on Discord. That is the role that gets mentioned. And with that, we hope to see y'all next week. Have a great week and we'll see you on the Discord. Thank you all. Thanks everyone. There are lots of thanks in the chat too. Thank you. Awesome.