Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 406, recorded Monday, October 21st, 2024. I'm Michael Kennedy. And I'm Brian Nockin. And this episode is brought to you by Scout APM. We would love to tell you more about them later. If you want to stay in touch with us, send us show ideas. We love it when people send us ideas like, hey, you should check out this because...
Brian, usually it starts with, I'm sure you've heard of this, but here it is. I'm like, I've not heard of that. And I really appreciate you sending it. So keep that kind of stuff coming. It helps us a lot, right? Definitely. And even if we have, we at most get a couple duplicates. That's fine. Yeah, yeah, exactly. If you want to stay in touch with us or send us things, find us on Mastodon or shoot us an email. Links at the top of the show notes. And do consider signing up for the newsletter.
The newsletter that Brian sends out every week just after the show comes out with everything we've talked about written down there. So you have it. Just get an email if you don't have a time to listen. Although we prefer people to listen. That's always fun. Yeah. I just think it's nice that people don't have to like write notes down while they're listening. They can just get it from the email later. Yeah. So pythonbytes.fm, click the newsletter button, enter your email. Everything will be good.
Brian, I want to listen to what you want to tell us about first. What's up? I think people should pay more money to open source. So I'm going to cover open source pledge. And I'm going to hop over to the Django site to begin with, because that's where I found out about it. Because the Django community, Django Software Foundation announced that they are supporting the open source pledge. And what does this mean? Well, the open source pledge is really simple to do.
All you have to do is you have to say that you're going to pay open source maintainers. Minimum to participate is $2,000 per year per developer at your company. So you don't have to count your salespeople. You don't have to count the janitor. Stuff like that. But how many devs you have, $2,000 per year seems like more than reasonable, because you know you're getting that much value out of open source. So you self-report.
So you pledge this, and then you self-report annually, click a blog or make a blog post to say how you've paid. Well, there's a whole bunch of, if you take a look, there's a list of members already. And I'm not sure how long this has been out, but the list of members includes people like Sentry, have 135 devs. And they're pledging 3,704 per dev, which is pretty cool. Laravel's in there, so it's not just Python people. And yeah, a bunch of great names in here. So what is this? Oh, button down.
That's nice. Even one dev. They're doing 5K per developer, but it's just nice. Anyway, so Django says, let's do that also. And to help make the Django community more sustainable. And I think this is great. So they're pledging it. I don't know how many devs the Python Software Foundation has now. We know they have at least two full-time, but I think it's growing. So that's pretty cool. So I think this is a great idea. And it's neat. I pledge your support for open source.
It's an interesting time for money and open source. And I do think it's a good idea as well. But there's some crazy stuff. Yeah. See WordPress. It's so insane. But that's not pledging money to open source. That's something else entirely. I do want to put this up there, but I do want to point out there's a cool post by Armin Roeneker who talked about the inevitability of mixing open source and money. And also just give a shout out to Sentry, who I believe this open source pledge was their idea.
And Armin was behind the launch of it. So well done, Armin. Well done, Sentry. You know, Sentry's a big sponsor. Yeah, a big sponsor of Talk Python. So, and I believe they sponsored Python Byte some as well, but certainly Talk Python. But there's, if you want to see a bunch of interesting reading, I'll put that article in there as well. But moving on, let's talk about TV. Let's watch some TV, Brian. Okay. What's on tonight? Catch the nightly news, Three's Company, Four, maybe some Django.
So I believe this project is put together by Jeff Triplett. So well done, Jeff. And it's called Django TV at DjangoTV.com. And the idea here is these are videos from, it's like a kind of a little mini YouTube-like thing, sort of, but for all the conferences. So, you know, you want to see the conferences at DjangoConUS of 2023. Boom. There they all are. You want to find all the videos about HTMX. There are many because HTMX is awesome and so on.
Search for it and see friends of ours up there speaking and doing things like that. So not a big, deep thing to go into. However, it's nice, right? Basically, it's a curated list with the descriptions. You know, you always want to know, like, when is something published, right? That's often the thing with conferences. Like, I saw there was going to be a cool talk. It happened three months ago. Eventually, somebody's going to put it on the internet. Probably, we think. We're not entirely sure.
So you can come down here and just hit the RSS feed and subscribe to that. And it'll just, all the Django videos start popping up when you subscribe. Pretty cool. Yeah, it's pretty cool. And this is pretty new. So if you've got old videos or new conference videos that are not listed here, especially Django-related. Yeah, fix it. Fix it. Fix it indeed. All right. Well, that is my main one. Now, before we move on, let me tell you real quick about Scout APM. They're big supporters of Python Bytes.
So we appreciate that very much. So if you are tired of spending hours trying to find the root cause of issues impacting your performance, then you owe it to yourself to check out Scout APM. They're a leading Python application performance monitoring tool, APM, that helps you identify and solve performance abnormalities faster and easier.
Scout APM ties bottlenecks such as memory leaks, slow database queries, background jobs, and the dreaded N plus one queries that you can end up if you do lazy loading in your ORM. And then you say, oh, no. Why is it so slow? Why are you doing 200 database queries for what should be one? So you can find out things like that. And it links it back directly to source code so you can spend less time in the debugger and healing logs and just finding the problems and moving on.
And you'll love it because it's built for developers by developers. It makes it easy to get set up. Seriously, you can do it in less than four minutes. So that's awesome. And the best part is the pricing is straightforward. You only pay for the data that you use with no hidden overage fees or per seat pricing. And I just learned this, Brian. They also have they provide the pro version for free to all open source projects.
So if you're an open source maintainer and you want to have Scout APM for that project, just shoot them a message or something on their pricing page about that. So you can start your free trial and get instant insights today. Visit pythonbytes.fm/scout. The link is in your podcast player show notes as well. And please use that link. Don't just search for them because otherwise they don't think you came from us. And then they'd stop supporting the show.
So please use our link, pythonbytes.fm/scout. Check them out. It really supports the show. Brian, over to you. Yep. So I'd like to talk about dependencies a little bit. So projects have dependencies. We often stick them in requirements.txt files or PyProject.toml files. But there's a new PEP that just came out. Well, it's been out for a bit. It was created in 2023, November, but it just got resolved. And so I think it just got accepted recently. So the resolution date of 10th of October.
So PEP 735 is dependency groups in PyProject.toml. And my first glance at this, I'm like, don't we already kind of have that in extras? But that's addressed by this PEP. So the idea is that we have other dependencies, not direct project dependencies, but extra stuff, like when you're building your docs or you're running your tests or things like that. So how do we specify those? And there's a couple of ways that people have done it in the past. One of them is the extras in PyProject.toml.
But preceding that, even before we had that, there were extra requirements.txt files. So some projects have a main requirements.txt file. And then some of them have a requirements.dev file or requirements.doc file or something or several. And the problem with that really is that there's no standardization around it. And then also there's not really a standardization about the requirements.txt file. It's just whatever you can pass to pip install.
And so like even flags and stuff, which is actually kind of fun. Anyway, tangent. But so that's, I don't think a bunch of requirements files is the right answer. How about extras? Well, I was surprised to find out that the extras that you can put in extra dependencies or optional dependencies, these are, these might not, I learned that they're, they're using, they're, they might not be resolved. What am I trying to say here? They, they're not guaranteed to be statically defined.
They could be dynamically defined. And, and that I just didn't even know. So we do need it to be statically defined so that, so that, you know, tools can read it easily. And there's other limitations around using the extras as well. Also, I think it's just, I think extras confuses people. I know it's a feature of pyproject.toml, but I was confused by it at first, had to like, like study it for a bit. And it just somehow doesn't, doesn't fit right away with a lot of people's mindset.
But these dependency groups look pretty good. So let's take a look at one example. So their example in the PEP just shows you get a block of dependency groups section. And then there's stuff like test with a list of, a list of things like pytesting coverage. Docs might have Sphinx and, and the Sphinx read the docs theme. Typing for doing type checking, like my py and type requests. So these all totally make sense. And then there's a, there's an extra bit about being able to group others.
So you could have a dependency group that includes other groups. That's pretty cool. And then there's some details around like, well, what happens if they conflict with each other and stuff? So that's well-defined, which is good. But I just think like having something like this, like a small block that say, Hey, for tests, we use pytesting coverage for docs. We use these and have that be nice and succinct in a dependency group section. I like it. So this has been accepted.
I'm not sure when it's going to come to a pip near you. But it's pretty cool. There, there's an example of how it might work at the end. Like how, I don't know, reference implementation, how it might work of like saying maybe pip install dependency groups and be able to install that. But, but that's up to PIP, the pip maintainers to figure out how, how that's really going to be used. Other interesting thing is extras are extras.
Extras are on top of the normal thing, everything needed for the, for the system. But for example, like when you're doing the documentation build, you don't actually have to build your thing to build the docs. So these dependency groups do not, they're not extra, they're independent. So you could build the, install the documentation dependencies without installing the project, which is pretty interesting. So anyway.
That's, that's one of the differences they highlight is the extras require, they add onto the base requirements. Whereas this, you can have one set of things installed for one scenario and another for another without necessarily overlapping them, which you might think, whatever, right? It doesn't matter. Just install some extra stuff. But there's certain things that say work in production, but won't install on windows. For example, right?
I think last I looked, UV loop didn't work on windows, but it was like a speed up for async IO on Linux. Well, there also might be a, an incompatibility of a dependent library on like your, if you're using Sphinx, maybe Sphinx depends on something that's a different version than what your project depends on. Yeah. Yeah. Yeah. Good point. So indeed Henry on the audience throws in that extras are public. These are not, unfortunately we lose the ability to guarantee the package was installed.
Sometimes you want this. Sometimes you don't. Thanks. Yeah. Um, hat tip to a transition. You didn't know what's coming. So overhead talk by the on training. We have a free course called static sites and API docs with Sphinx, Python and Markdown done by Paul Everett. And he unwittingly introduced me to this next topic through that course on here. Live reload as in pip install live reload. Do you know this?
No. So it's kind of a generic file watcher, mostly focused on web apps, but you could use it for literally anything. And it's just, you can say, here's a set of file patterns, multiple ones. And it can, you can use the star star slash something to like look at sub directories and whatnot. You know, the, the file pattern craziness to however much you want. And then if something changes, it will just run an arbitrary shell command for you and potentially restart your web app as well.
If you give it a web app, like a flask or Django, a whiskey app type of thing. So that's pretty cool. If you look at the documentation, you will find it to be sparse. Like the description of it literally is about eight words, one sentence. It tells you how to install it, but like, well, okay. But why would I install it? You look at the API reference and it's, it's basically just a signature.
So if people are looking to contribute to a project, you know, maybe given this a little example, a little bit of a, a few paragraphs would be awesome. But, I gave you an example that we can all use from Python bytes and from talk Python, similar apps. So similar use here.
And so I, I'm sharing a gist with folks that will, if you run it a little file here, you can just run this as in your terminal or just however you start it and just leave it running while you're working on a project and what it'll do. It'll track down using pathlib. It'll track down the root folder and then find a CSS folder and a JavaScript folder. And then it'll run Python against some file that does bundling.
So for example, at Python bytes, we take maybe six or seven CSS files and minify and bundle them into a single one in a certain order. And then share that over a CDN. Yeah. And so depending on how it's running, you may or may not see those changes if you're doing like CSS design stuff, same thing for JavaScript, right?
So what you can do is you just set this up, pointed the right places on your file system, say, watch the CSS folder, watch the JS folder and run a shell command, which is tell Python to run that Python script that does the bundling. Boom, off it goes. And you just run that in the background while you're working. What do you think? That's pretty cool. So with this, if you change the JavaScript and CSS, it just automatically updates then? Right.
It looks for any file change within the search pattern, like star star slash CSS slash dot star dot CSS or whatever, you know. And then if it sees that, it just runs the command, which the command that I gave it is to run Python to rebundle our assets. So for whatever reason, because one of the things that can happen is, you know, change something about a CSS file, forget to bundle it, publish the site. And you're like, huh, why does that look so weird? Like, why is that not changed?
But the, you know, the, the, the, the packed version of that one that runs in production, but not in development is out of sync. And then it's weird. Right. So if you just, as long as you have this running somewhere, just chilling, then you're good. Cool. But it doesn't have to be, I mean, the context is web and it's very focused on static websites, which is super annoying. Like the way you run it, as you say, server dot serve, and it literally starts up a web server at some route you give it.
But I don't want to look at it. I'm not trying to look at the website through it. I literally just wanted to run the file. So there should be some secondary command, like just start watching or something like that in the background. But it starts a little web server. You can just ignore it and, or point it to nowhere and ignore it. And then you could get it to do basically when a file changes, run a shell command of your choosing, which is pretty flexible. Yeah. It does.
I guess to give them a little credit, they do have pages for how to, how to use this with Django and Flask and Bottle. I don't know anybody that uses Bottle anymore, but. No, no, I know. But I mean, the pages for it. But unnecessarily the right details. Yeah. It doesn't like, it doesn't really tell you what happens. Okay. It just shows you what to do. And then you can imagine, well, will it restart the app or will it not restart the app? Will it just restart the CSS?
Will it reload the templates? There's options of what could be happening, but it doesn't really say. Anyway, it's a cool project. I would love to see a little bit more description just so that I can get a little more traction. But yeah, there you go. Paul was using it for when he changed a markdown file in the course. It would run make HTML out of Sphinx to automatically rebuild the website as you just typed in it. Oh, that's cool. Yeah. All right. Well, do you want to jump into extras?
Let's jump. Okay. Do you want to hit yours first? Yeah, I'll go first. Mine are super short. So, a couple of things. First of all, I was looking at our Umami. That is Umami Analytics. Is it .is? I think it is. Umami.is. Analytics. Yeah, perfect. And I noticed something unusual, that 14% of our listeners are from Germany. Oh, that's cool. That's pretty interesting, right? Especially given, you know, this is in English. It's not their native language.
But, like, more than Australians, the Germans are listening to our stuff. So, thank you, Germany. Maybe we should have a competition to try to get the country. Exactly. Exactly. And then, not that I intended this to be a German episode, but here are German extras. But, the German company, Hetzner, have you heard of them? They're like DigitalOcean, Linode, so on, AWS. So, I've heard a few people talk about them. And they have really interesting hosting models.
Like, they'll give you super affordable VMs, lots of bandwidth, so on. So, for example, for an 8 gig, sorry, 16 gig, 8 CPU server in DigitalOcean, it's $112. And it's hard to tell exactly on AWS and Azure, but I believe AWS is $200 and Azure is $350 per month, okay? Okay. I go over here to Hetzner, prices, and you pick, say, shared AMD, and you pick your country to be US. Come here. Oh, where'd you go? Same server is $25.
Wow. And it comes with 20 terabytes of bandwidth, which, quick math, I believe that's about $2,000 at AWS. Okay. And that's included in the $25. Cool. So, the news is, why am I even mentioning this? The news is, they recently came to the US. All right. They used to be just a European company. Now, they're available in the US. So, that opens up a lot of interesting hosting possibilities. Are you switching anything? I'm thinking about playing with it. We'll see how it goes.
I actually asked people in Mastodon, what do you guys think about this company? And I got a lot of German folks who said they're having a lot of good experiences with it. So, we'll see. Okay. But I'll let you know if we do. I haven't switched anything around. But it's pretty interesting, right? That you can get so much compute for so affordable. Yeah, that's pretty cool. Anyway, those are my extras. Over to you. A couple blog posts that I wanted to highlight that were kind of neat.
K.J. Miller. Personal blogs are no longer personal when AI gets too involved. So, I know people are using AI and chat-like things to come up with some ideas and stuff. And that's pretty much what K.J. Miller is talking about. It's not necessarily terrible to do that. But be careful what you're doing and why you're doing it. So, for instance, coming up with ideas or if you're stuck on how to phrase something, having somebody help with that is great. And writing is hard.
So, getting some advice, fine. But it should still be your voice. So, I love, I was wanting to hop down to his advice. It says, obviously, if you're reading this and not, obviously, if you're reading this and not getting ChatGPT to summarize it for you, you care about my words to some degree. So, you are reading somebody's blog for their voice. So, keep that in mind when writing your own blog.
So, especially if you're writing a blog to try to get hired later, it doesn't help you any to just regurgitate some ChatGPT stuff and copy and paste it. We don't need more people like that. I mean, if you're doing it to try to fill up your blog for selling something, I still don't like that, but you know, your business. But if you're trying to do it to highlight what you write like, then you need to write it. And also, if you're doing this to help your future self, make it personal.
Also, like, if you're not writing it or at least rewriting it, writing it in your voice, it's not going to stick in your head. So, you're not doing yourself any favors. There is a bit about, he talks about if you're doing this to create content in another language, learn about that community's writing style, which makes sense. But I kind of think there's translation tools already built into some browsers.
And if somebody from another country really want to read your stuff, maybe they probably will anyway and translate it if they want to. So, I got really no interesting opinion about that. But I think I like these ideas about if you're doing it to gain, you know, build your personal brand or put yourself up as an expert in an area, using AI to do that's really not helping you. I think people can figure that out because there'll be an inconsistency in writing styles in different posts.
And then also, it's your personal thing. People are trying to reach you. So, be you. Anyway, that was one extra. The other one was something that I just didn't think about, and I probably should, is mind your image metadata. This is an article from Stephanie Molin right there at the top. She presented at PyCon Estonia. Anyway, the talks about the EXIF interchange format. Basically, pictures have tons of metadata in it.
And if you don't want to have that published everywhere, and you might not, you might not want personal locations for exactly where your photos are. She talks about how to tell using tools to figure out what's in there and also talks about tools to rip them out. And then even talks about using a pre-commit hook to strip out pictures that you're including as your static images or in your Git repo. That's cool. If you're putting your Hugo static site, just none of it has any of that in there.
That's a pretty cool idea. I like that. Those are just my two extras. Excellent. I'm having Stephanie on Talk Python Thursday. Cool. Three or four days from now. Sweet. Yeah. All right. How about our joke? Let's do it. Okay. How are you? This is a dumb joke, but I love it. It's an oldie, bitty, goodie. I'm linking to a savvy programmer blog, but I've heard it before. Essentially, it's, okay, a programmer's partner asked them, hey, would you go get a loaf of bread from the store?
And if they have eggs, grab a dozen. So while later, the programmer returns with 12 loaves of bread and says they had eggs. So literal. I love it. Anyway, there's a handful of jokes here. Pretty decent. Okay. I didn't read very many. I'm going to go check some of them out. That's awesome. Anyway. Excellent. Yeah. Very funny. Thanks again for the show together. And everyone, thank you for listening. Talk to you later.