Python Bytes - #406 What's on Django TV tonight?

Episode Date: October 21, 2024

Topics covered in this episode: Open Source Pledge Jeff Triplet's DjangoTV PEP 735 – Dependency Groups in pyproject.toml livereload Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/406

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 Ocken. 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 you, 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 you, even if we have what we at most get a couple duplicates, that's fine. 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 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. 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 2K per year seems like a whole bunch of, if you, 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, the list of members includes like, you know, people like century of 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 OneDev, they're doing 5K per developer, but it's just, it's nice. Anyway, so Django says, let's do that also.

And to help make the Djangoango community more uh sustainable um and and i think this is great so they're pledging it um i don't know how many devs the python software foundation has now like we know they have at least two full-time but um i think it's i think it's growing uh so that's pretty cool so uh 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, I wasn't going to put this up there, but I do want to point out there's a cool post by Armin Roeneker, 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. Sentry's a big sponsor of TalkPython. And I believe they sponsored Python Byte some as well, but certainly TalkPython. Sentry's a big sponsor. Yeah, a big sponsor of TalkPython. And I believe they sponsored Python Byte some as well, but certainly

TalkPython. 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. What's on tonight? Catch the nightly news, Three's Company, or

maybe some Django. So I believe this project is put together by Jeff Triplett. So well done, Jeff. And it's called DjangoTV 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 want to see the conferences at DjangoCon US 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, when you subscribe.

Pretty cool. Yeah, it's pretty cool. And this is pretty new. So if you've got old videos or, or new conference videos that are not listed here, especially Django related. Yeah.

Fix it. Fix it. Indeed. All right. Well, that is especially generic related. Yeah, 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 Byte, 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 youed 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 slash 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 slash 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 um well it's been out for a bit uh 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 um 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, this, this pep. So what the idea is that we have other dependencies, not directly wrote, 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 ways that people have done it in the past. One of them is the extras in pipedroject.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 a extra dependencies um or optional dependencies these are um these might not uh i learned that they're they're using there there might not be resolved what am i trying to say here um they they're not guaranteed to be statically defined they could be dynamically defined. 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 PyTest and coverage. Docs might have Sphinx and the Sphinx read the docs theme. Typing for doing type checking,

like mypy and type requests. So these all totally make sense. And then 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 by testing 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'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 that's up to pip, the pip maintainers, 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 um dependency groups do not they're not extra they're independent so you could build the install the the documentation uh 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 on to yeah the base requirements whereas, 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. 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 an incompatibility of a dependent library on like 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. 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. Hat tip to a transition you didn't know was coming. So over at DocPython 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 is a set of file patterns, multiple ones, and it can, you can use the star star slash something to like look at subdirectories and whatnot. You know, the,

the file pattern craziness, 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, 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 giving 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, 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, point it at 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 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 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 use this with Django and Flask and Bottle. I don't know anybody that uses Bottle anymore. No, no, I know.

But, I mean, the pages for it. But not necessarily the right details? Yeah, it doesn't really tell you what happens. 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 is super short. So a couple of things.

First of all, I was looking at our Umami. That is our Umami analytics. Is it.is? I think it is. dot is analytics yeah perfect uh 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 the Germans are listening to our stuff. So thank you, Germany. Maybe we should have a competition to try to get the country.

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, Zon, 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 eight gig, sorry, 16 gig, eight CPU server in DigitalOcean, it's $112. It's hard to tell exactly on AWS and Azure, but I believe AWS is $200 and Azure is $350 per month.

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's $25. Wow. and it comes with 20 terabytes of bandwidth which quick math i believe that's about

two thousand dollars at aws and that's included in the 25 dollars cool so the news is why why am i even mentioning this the news is they recently came to the us they used to be just a European company. Now they're available in the U.S. 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 on Macedon, 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. 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, it's pretty cool.

Anyway, those are my extras. Over to you. A couple of 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 KJ Miller's talking about

is it's not necessarily terrible to do that, but be careful what you're, what you're doing and why you're doing it. So for instance, um, um, coming up with ideas or if you're stuck on a, on how to say phrase something, having, having somebody help with that is great, but, um, and writing is hard. So getting some advice, fine, but it should still be your voice. So, uh, I love, I was wanting to hop down to his advice. The says, obviously, if you're, if you're reading this, and not, obviously, if you're reading this and not

getting chat GPT 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 chat GBT stuff, copy and paste it. We don't need more people like that. I mean, if you're doing it to try to like, you know, 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. Um, and also, uh, if you're doing this to help your, your future self, make it personal. Also, like if you're not writing it

in, 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. Um, there is a bit about, uh, he talks about if you're not doing yourself any favors um there is a bit about uh 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, and then also it's, 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, oh, from Stephanie Mullen, right there at the top. From, 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. So that's cool. If you're putting your Hugo static site, I'm sure 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. And yeah. Excellent. I'm having Stephanie on TalkPython Thursday. Cool. Three or four days from now. So yeah.

All right. How about our joke? Let's do it. Okay. Over to you. This is a dumb joke, but I love it. It's an oldie but a 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.

So I didn't read very many. I'm going to go check some of them out. That's awesome. Anyway. Excellent. excellent yeah very funny thanks again for the show together and everyone thank you for listening talk to you later bye