Python Bytes - #419 Is your back end popular?

Episode Date: February 4, 2025

Topics covered in this episode: content-types package for better MIME types/Content-Type Wagtail 6.4 Build It Yourself Build backend popularity over time Extras Joke Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training The Complete pytest Course Patreon Supporters Connect with the hosts Michael: @[e-mail] / @mkennedy.codes (bsky) Brian: @[e-mail] / @brianokken.bsky.social Show: @[e-mail] / @pythonbytes.fm (bsky) Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Michael #1: content-types package for better MIME types/Content-Type It started with this comment from Raf. mimetypes — Map filenames to MIME types It is oddly missing very common types and varies by platform, OS install and other factors (see this function). Search around and found python-magic. Seems great but ImportError: failed to find libmagic. Check your installation → brew install libmagic magic.from_file("testdata/test.pdf") → FileNotFoundError: [Errno 2] No such file or directory: 'testdata/test.pdf' hmm So I had to create my own. Introducing content-types A Python library to map file extensions to MIME types. Unlike other libraries, this one does not try to access the file or parse the bytes of the file or stream. It just looks at the extension. Better support than mimetypes builtin. Brian #2: Wagtail 6.4 Release notes Lots of great updates, but I want to zoom in on background tasks. 6.4 includes django-tasks which is an available implementation of DEP 0014: Background workers This proposal is accepted and this thread includes a great talk from DjangoCon Europe 2024 Why is this cool? Even though django-tasks says it’s “under active development”, as long as you pin the version and test your behavior depending on this, it must be ready to use if wagtail is going for it. Don't you think? Michael #3: Build It Yourself from Armin Ronacher, sent in by Rafael Weingartner An excellent article pushing back on too many dependencies Maybe the advice of always prefer code reuse isn’t that great after all? It’s much much easier to solve small little problems these days due to AI. Take Postmark as an example. “It's time to have a new perspective: we should give kudos to engineers who write a small function themselves instead of hooking in a transitive web of crates. We should be suspicious of big crate graphs. Celebrated are the minimal dependencies, the humble function that just quietly does the job, the code that doesn't need to be touched for years because it was done right once.” - Armin Brian #4: Build backend popularity over time Bastian Venthur This is just for projects using pyproject.toml Apparently he did this last year as well, so we can see some trends. Results setuptools: ~50% (last year ~50%) poetry: ~30% (last year ~33%) hatchling: (percent not listed, but looks like 12-15%), (last year 10%) flit: ~5% (last year ~10%) other: (above flit now) Analysis: setuptools continues to grow in absolute numbers and maintain it’s percentage. poetry declining hatchling growing flit declining Brian commentary This is not surprising to me. I generally use hatchling for more control, and setuptools for simple projects. I think we might end up with mostly setuptools and hatchling in a couple years. Extras Brian: Test & Code Archive is now all episodes on one page Old method was 30 episodes per page For something completely different NameGrapher - popularity of US names No wonder I don’t meet a lot of kids named Brian Michael is #16 (#1 in 1950s - 1990s) Brian is #317 (#8 in 1970s) Joke: The long path to rejection.

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 419, recorded February 4th, 2025, and I am Brian Ockett. And I'm Michael Kennedy. And this episode is sponsored by us. Check out our courses at either pythontest.com or talkpython.com. No, wait, that's right, isn't it? Talkpython.com will work. Yeah, that's right. Also, thank you Talkpython.com will work. Yeah, that's right. Also, thank you to our Patreon supporters.

We don't thank them very much, but they do help with the show. So thanks. If you'd like to connect with the show, please hop on Blue Sky or Mastodon. And the links to both Michael and myself and the show are in the show notes. And if you'd like to join us live, it's Tuesday today, but normally it's Monday. Normally Monday at 10 at Pacific time. Go to pythonbytes.fm slash live.

And finally, we are getting some great feedback about our updated beefier show notes with deep dives. So we in the email list. So if you'd like to get some background around all the topics we cover and a little more info than what we have in the show notes, join the newsletter.

Just go to pythonbytes.fm and it's really easy to figure out. Definitely is. You should check it out. And there's a lot of great content there. And it's an email type content that i was trying to go into the first topic there we'll get there we'll get there so yeah if you're gonna attach something maybe we'd have a mime type like a graphic or zip file or something so last week this is like

groundhog day mime types mime type. about that? Yeah. Well, got some nice feedback from folks, including Rafe Guns, who said, hey, you mentioned mimetype.io. That reminds me of something that happened just last week. I need to map file names to this. And I thought, surely someone's already done this. And it turns out that the standard library already has a built-in mimetypes. And you can ask it, hey, what what is given this file name what do you think its extension is okay so even better right well well well no not so fast this sent me down such a rabbit hole okay so there are weird things that this MIME types library does like there's not

that many and especially for the common ones, it's a list of like a hundred or something, you know, but if you look at the implementation and see Python for MIME types, what it does is it looks at a set of files that come with each different operating system, Raspberry Pi, Ubuntu, Mac OS, Windows 7, whatever. It, it doesn't have a single built-in MIME type. Like it won't tell you what they are. It doesn't know what text.txt is. It doesn't have a single built-in MIME type. Like it won't tell you what they are. It doesn't know what text.txt is. It doesn't know what HTML is. It just looks at these files,

which is really weird to me because that means you get different answers for MIME types based on your operating system. Like Docker might, if you run Linux in a Docker container, it might give you different output than say desktop Linux and stuff. Real, just thinking, you know,

for like 30 seconds around this, it seems like maybe you should build in all the known ones. And then if it overrides it, like something special about the machine configuration says this MIME type is something different, maybe consider overriding it with a local file definition, but just omitting them all very weird. Plus it'll tell you things that are wrong. Like that XML should be text slash XML, not application slash XML. Okay. So that sent me looking, I'm like, well, that's not great. Surely there's something

on PyPI. So I looked at for like Python magic and Python magic is awesome. What it does is you give it a file. It's based on lib magic, but there's some kind of C library or something. So you got to install that with brew, which is kind of weird, but okay, fine. So you got that. And then what it does is you say, hey, given this file, like this PDF, tell me what kind it is. And it says, hey, this is application.pdf. But the way it knows this is it goes and it actually reads the file. It doesn't just look at the extension.

It goes, ah, you said it's a.jpeg. But when I looked at it, I inspected the binary header for the image, and it looks like it's a PNG. So we're going to tell said it's a dot jpeg but when i looked at it i inspected the binary header for the image and it looks like it's a png so we're going to tell you it's png super helpful when you're talking about the file system super duper unhelpful when you're building web applications you know like when you need to specify the mime type because what if your image lives in s3 storage how are you going to ask what i should return if I want to link, just redirect someone to it? I've got to download it from S3, feed it to the thing,

throw away the temporary file, and send it back. And all these other ones, they all look at the files. Like, if you don't look at the file, how are you going to know? It's like, okay, if you want to be super thorough, yes. But what if the file's in a database?

The file's in, like, remote storage. Like, you don't want to go get the file. You want your best guess, right? So Brian, this has led me to create github.com slash Mike C. Kennedy slash content dash types available on PyPI as content types. So it does exactly what you would think. It tells you given an extension, what is the MIME types? It even includes a CLI.

So you can say like after UV tool install it, you can just say type content types anywhere in your terminal, give it any form of file name and it will tell you what comes out. That's kind of handy. So if you're curious, it has way more content types than the MIME types and they're correct.

That's always good. We'll talk about that in a second. But you just say content types, get content type. You give it some kind of file name as long as it has an extension. It doesn't matter if it's a HTTPS to some file or it's just a file path on your hard drive. If it has an extension, we'll be able to tell you

what its MIME type is. So is this just a big lookup of extension to type? Or something like that? Pretty much, yeah. It's like a massive, massive lookup of those things. But the thing is gathering them all up, right? So for example, if you look at the built-in MIME types, like, well, why don't you just have MIME types

and use that? One, it varies. But two, it's wrong about things like if you ask MDN, Mozilla Developer Networks, what.xml should be, it says it's application.xml. It used to be this older text.xml. It's not anymore.

But the built-in Python one says it's the old style. It's also missing things like TGZ and GZ zip and FLAC and EPUB and all these types you would expect. So anyway, I didn't spend that long. I spent a few hours building this thing, but I'm like, there, I fixed it. It doesn't depend on the operating system. It doesn't have to read the file. You don't have to download it from S3 storage

to tell you what it is. It just, it just given a file name. It'll tell you what the content type is or MIME type. Somebody asked, why don't you name it MIME types? I'm like, I don't know really how to import something that overrides a built-in as a third-party package and make that useful experience. You know what I mean?

So anyway, that's what it's called. So hopefully this helps people. It's built in Python. It has something like 180 different types and it has 31 types that are not known to the built-in library. Common stuff, like I said, like fonts or M4As, audio files,

or WebAs for other audio files, or W, a lot of stuff, right? RARS, Ttf that seems like you should know what that is anyway i present to the world this project i worked on over the weekend nice i like it yeah thanks always threw me the m4a's were audio mp4s like yeah i know it's m4a it's not mp anyway um but since I, I work with audio as well. So, hey, good job, I think. And let's talk about Django a little bit.

So Wagtail, Wagtail 6.4 is here. There's an announcement. Enjoy a smoother content experience with Wagtail 6.4. I don't actually use Wagtail 6.4, but, or Wagtail, but, but, but I play one on TV. No, but there's, it's, I'm glad Wagtail 6.4 or Wagtail, but I play one on TV. No, but I'm glad Wagtail's here. It's a really cool platform, content management system built on top of Django. Why am I bringing this up? It's great that they've got a release and there's some cool stuff.

But the thing that I really am excited about is if we go down, it says it's this version incorporates Django Tasks library. And that's the cool that's a cool bit, according to me. So the Django Tasks library and there's a release notes to that will link to it also is pretty excited about the Django Tasks. So what are Django Tasks? Let's see. Oh, yeah. Oh, by the way, some of the cool things about um about wagtail it's used by nasa and google and nhs and some of those are still operating uh so um django tasks is a is a if we look at it it says it's a backport but it's it's really the it's really the implementation that you can play with right now of a thing defined in DEP 14.

And that's a Django enhancement proposal for background workers. And this is accepted. And one of the things, whether you love it or hate it, Django enhancement proposals don't happen quickly. Partly it's because they do LTS support and they really don't want to break things. And they just don't happen fast. But that's OK. We love you, Django. But the so Django tasks is background workers around.

Yeah, but just background workers into Django Core. There's a talk that was given at DjangoCon Europe 2024, and this is a great talk. Listen to this, talking about how really the normal, the cycle of a webpage of of like, you do a request and then a response, that doesn't work for a lot of stuff and you need background tasks and other tasks to run at different times, or even just later. Like, you know, you don't have to wait, we'll work on it. So that's cool.

So, and so now the implementation of this is being done in the Django test application. And you can use it. And since Wagtail is using it, I think it's pretty stable. And I think people should feel free to use it and provide feedback if you run into any issues. So they're really ramping up trying to get all the kinks out. So pretty cool. Yeah, that's really cool.

I think a lot of times people overthink how much infrastructure you need to say, run something in the background, like, oh, this thing takes five seconds. And if we do it on the view call, then it's going to slow down the website all bunch. So let's set up Celery and Redis and a queue and like, whoa, it was running all on its own until just a second ago. Things like this, where it's kind of just a background thread, like, okay, well, we just kick it to a second ago. Things like this where it's kind of just a background thread, like, okay, well, we just kick it to the thread and maybe you want to log it to a database or send an email, but you're going to take a second, so just let that happen.

Yeah. It's great. And also, for people that are thinking about using this Django tasks project to put something in place, I think that's where I would lean, partly because that's where Django eventually is going. But also, you've got Wagtail as an open source project. You can look to see how they're doing it.

So you can look to see how the project's implemented. Yeah, excellent. Excellent, excellent. And by the way, Brian, are you familiar with all the WordPress drama? Have you been tracking this? Yeah. Oh, it's so insane. People, if you haven't been tracking this, WordPress has gone off the rails. So maybe if you're out looking for, I don't know, a different CMS instead of WordPress, Wagtail, check it out. Less drama, this is something of a rant and a call to arms, if you will, to depend less,

depend less, saying, look, there's a lot of pressure and encouragement to say, if there's anything that you can use as a third party dependency, rather than building it into your own code, do that. That's how you stay agile. Unless it's not. Unless it just becomes a drag. You know, if you have one function that you need, and there's some library that has 100 functions, and it does a whole bunch of stuff, but it has that one thing you need, you could depend upon it. But then what if you want to go to Python 3.14, and it doesn't upgrade in time,

and you're stuck, right? And you know, one library, that's one thing, but then you multiply that times 100 and it gets real complicated real quick. So he pulls out an example and says, look, what about terminal size? This is mostly speaking in Rust terms, but it equally applies to Python. So that's why I'm covering it.

It says terminal size is a package that you can use and it tells you the size of the terminal, like 80 by 25 or 47 by 100 or whatever the rows, columns of the terminal is, it tells you that, right? Well, that thing has been pretty much unchanged for a long, long time, but it's had 26 releases

because the stuff that it depends upon has been churning and has to be, you've got to use a newer dependency of this library so that your thing will build on the new version of the runtime, right? Instead of just being basic, right? Why, you know, if terminal itself, terminal size itself hasn't changed,

why do you have to keep rebuilding it, re-releasing it? Here's a funny term, but big supply chain will tell you, you must do it this way. Big supply chain. Yeah, exactly. It's like big tobacco, big supply chain. And as well as open source people, right? They're like, oh, you know, why are you putting this in here?

You could just use this library in this, this pull requests or similarly for code reviews at enterprise places. And there's one quote I want to read to you all about it and then kind of leave it there. It says, it's time to have a new perspective we should give kudos to engineers who write a small function themselves instead of hooking in a transitive web of packages we should be suspicious of big dependency graphs celebrate celebrated are the minimal dependencies the humble function that just quietly does the job and the code doesn't need to be touched for years because it was done right what do you you think, Brian? I take issue with this. Okay. Okay.

I get the idea, and I agree with, for some things, like something like terminal size, I don't know how to determine a terminal size, but I imagine that I would probably pull in a library or something to do that, but I wouldn't expect that it would have to pull in a lot of stuff yeah um so if like i really you know there's a lot of like um there's a lot of stuff i depend on because i don't want to figure it out um but i also don't really want those things to be too deep you know for instance um yeah but that's our that and that that's the that's the trade-off you you

either either you know they so what's the problem so what's the problem-off you, you either, either, you know, they, so what's the problem? So what's the problem writing yourself is because you don't, you're not, if you're not the expert in this field, why would you think you got it right? Um, uh, I wouldn't necessarily think it was right just because there's a package for it, but, uh, I know I'm not an expert at it. So that's why I grabbed a package. And also I don't want to think about like security problems and other things in the future. If there's a issue with certain packages, like, why do people use stuff like Redis? I'm sure you could just write a caching system on your own. There's reasons why we use these packages. Yeah. And to be fair, Armin says, look,

it's not black and white. They're important libraries that solve hard problems like web frameworks and graphics libraries and things like that. Right. But I think it's more like left pad. Yeah. Do we really need a library with three dependencies to just pad a string? Probably not. I don't think we do that that much in Python, though. Or maybe we do. Not as much. Not as much. But I'll give you an example. Like, so I started working with Postmark. I'm trying to move away from SendGrid, not going as good as it could, I suppose. So I'm like, oh, Postmark. Awesome. This is, you know, similarly priced.

Seems to be pretty reputable. They really cracked down on spammers, which is the problem with SendGrid from what I can tell, at least my personal experience. So it says, okay, look, if you want to use it, there's official libraries. You just go over here and grab one. Like, boom, there's a Rails gem. There's a.NET Postmark library. There's a Java one.

There's a PHP one. There's a Craft. What the heck is Craft? But anyway, there's one of them. There's a Node.js one. There's a CLI one. There's one for WordPress. There's one for Grunt and one for Zapier.

The most popular programming language in the world is missing. But, you know, I don't know. Whatever. Whatever. So probably PyPI. Probably PyPI has one, right? Here, the most popular programming language in the world is missing, but I don't know, whatever it is, whatever. So probably PyPI, probably PyPI has one, right? Postmark email. Sure, that's cool. Okay, so there's this one called Postmark, the top one, updated 2017.

It has a single sentence, no documentation. If I go to it, I guess I could download it uh let's see let me try another one so what about this postmarker one um what versions of python oh this is actually pretty this works pretty well uh but you start looking through these and a lot of them are like oh man i don't know it's okay like here's one something for and django from 2011. one from flash from 2020 right but i wanted one for court right async it doesn't really matter it's courted i want one for Njango from 2011, one from Flash from 2020, right? But I wanted one for Cort, right? Async, it doesn't really matter if it's Cort.

I want one that supports Async. Yeah. Okay, here we go again. So I could try to work with one of those libraries and go, hey guys, can we think about adding an Async API to this? Or you can go to ChatGPT Pro, say, do you know what the Postmark API is? Yes, create me one that does async in a way

an async io based one that uses http x for its implementation bam got it it works fine you can stick that in your code off the race as you go right i don't have to worry about whether their library supports python 314 when it comes out or not and there's no security things because it's just me and postmark having a little chat and things like that. So I think, and I'm not saying like, don't use packages, don't contribute packages. I mean, literally I opened the show with like, here's my new package. But I think there are also, it's easier than ever these days to go, I need one function that does this thing. I like call this one API endpoint, like give me that function. Boom, here it is. So I don't know. I think there's some balance to be had yeah also um good api docs uh like it might be that postmark just has pretty

decent api docs and you could just build it yourself anyway or that i was gonna i was gonna build it myself and then i'm like well let me ask chad yeah sure and see if it gets it close and i'll tweak it if needed i'm like no it got it exactly right well that's cool it gets it close, and I'll tweak it if needed. I'm like, no, it got it exactly right. Well, that's cool. It even made the client not just use HTTPX, but it even made the async client an async context manager. So I can say async with Postmark client. Da-da-da-da-da. Off it goes.

I mean, it was sweet. Yeah. What I hope, I hope that people like Postmark and other services that have APIs that we're using, I hope they keep the documentation good and not think that people are just going to use AI to generate the stuff anyway. So you don't need the documentation. We still need the documentation because sometimes it's wrong or we have bugs or something has to be debugged. So anyway. Yeah. And by the way, if there was an official Python one

that had async support, I would have more than gladly used it. I didn't want to create my own. It just doesn't exist, right? And so maybe we could turn this around a little bit and say, if you're out there listening and you work for a company like Postmark that has an API and you're like,

well, it's too much to create an API client in Python. I bet it's not if you ask. Yeah, but then you have people in the house I bet it's not if you ask. Yeah. Yeah. But then you have people in-house to review it and say, yeah, that's probably what we want. Right. Then open source it and people can contribute to it. And yeah, but I think the zero to one, like, oh, we're not going to create it for this.

We'll just give people the docs and let them rewrite it like a million times across all the developers. I don't think that makes as much sense as it used to, because it's not that hard to create one these days. Yeah. Yeah, agreed. Cool. Yeah.

Anyway, thanks, Armin, for the cool article. Talking about building packages, though, I was curious what back end, build back end, you used. Do you use setup tools or Hatch or Hatchling? I use Hatchling for the build back on my PyProject.toml, and I use uvbuild uvpublish as the workflow. Okay, cool. I haven't done the uvbuild, but I haven't done the publish bit before.

However, so PyProject.toml, we've been following it on the rise of PyProject.toml on the show. And there's this i'm cracking up the there's a blog uh from bastian vent venter that's her sorry bastian um it the title of the blog is still don't have a title which is an awesome title for a blog um just saying uh he did this investigation both last year and this year. And it's about how with the popularity of build backends for projects using project. So this is the second,

second version kind of a fun, just little data set. There's, he actually uses data set. Nice. But the results are interesting. I think I'm going to pull up from last year and this year. So we get the same graph.

Okay, so last year we had Setup Tools was definitely in the lead, Poetry next, Hatchling, and then Flit, and then Other was about the same as Flit, maybe a little bit bigger. And then this year, looking at the graph again uh set of tools poetry but there's not as much growth in poetry uh hatchling is growing a lot more now and then that's a good job with that flits down and um and then the other is actually bigger than flit i don't know what all the others are um but anyway the uh what takeaway there's some and then there's some the plot shows a relative distribution over the quarters.

And you can really see there that hatchling is really growing and and flits actually on the decline. Looks like looks like poetry is kind of on the decline as well. A little bit. I think I would see I think there's just a lot more projects now. But, but I think hatchling is sort of taking some lead. I in this, this, this isn't really that surprising to me, because I, I think that set up what a big decline in setup tools for a while was because flit and hatchling were working so much better, but Setup Tools had some updates with being able to use it with PyProject.toml better.

And those updates, I think, have improved things. So I use both now. I'm using Hatchling for some projects, especially when I want fine control. But if it's really just a really simple thing, especially if I'm doing it in a corporate setting, I'll probably use Setup Tools because it's more mainstream. setup tools because it's, I don't know, it's more, it's more mainstream.

People know about it more. I don't have to explain anything. So just interesting looking at the trends for backends. Yeah, that's interesting. I wonder what the, you know, the sort of the default behavior for different projects, you know, if there's certain projects that will create like

popular cookie cutter templates or other things oh yeah that make an outsized impact on this i'm not sure nothing comes to mind but there could be something like oh this thing would be way lower except for it's used this it's used in this project that's used by so many people or something yeah yeah it would be interesting to know um what is when you say like i can't remember it oh uv has its own right so if you say um is does uva have its own build back in instead of building not that i know of i for the it just will build any pyproject.toml using the specified build back in as far as i know so for mine i put hatchling in my pyproject.toml then i just say uv build and it it does it yeah i'm just like you uv has a uv init so you

can initialize that pyproject toml i was i'm curious what back end it specifically is oh i have no idea i have to have to play with that you do your extras and i'll tell you the answer okay um i'll go to the i've got a couple extras um first off i'll jump ahead. So one of the things that we've got with Python Bytes, and I think you do this with Talk Python to Me as well, is there's a episodes page that lists all the episodes. I mean, it's one line each, so why not just list them all? So if you're curious about an old episode, you can take a look. I wanted this for testing code. So testing code used to be something like this. If you go to all episodes, it'll show the title of the episode and the information.

And then you see 30 of them. And then if you want to see more, you go to the next page. But I've got 225 episodes still. That's a lot of clicking to go through all of them. So the update I've got is that I'm handwriting this, but it's not that hard. I've got an archive page now

that has all episodes. So you can see all episodes of Test and Code. They're reverse ordered. And I think that's right for season one because there's a lot here. But for season one,

it was long. Yeah, I know. Nine lot here. But for season one was long. Yeah, I know. Nine years, 223 episodes. Yeah, whatever. Time for season two. And it'll probably be shorter than nine years for season two. We'll see. Probably.

But I might reverse these and have them one, two, three instead of three, two, one. We'll see. Anyway, that's my first extra. The second extra is something completely different has nothing to do with uh with python i just came across this thing called name grapher and um uh and i think it's it's around about like us names and uh because i was curious why we did where there weren't any bryans around anymore but the peak of brian was 1970 um and i looked up michael also um michael's been popular michael i got a little broader distribution but still extremely 70s kids but

it was it was the number one uh name in the uh 60s 90 60s 70s in 80s and 90s i think or something like that it's been number one for a long time. So you're popular. There's a lot of money. My wife always jokes that if she yells my name in a supermarket, like three guys will turn around. Yeah. Anyway, it's kind of fun to look up some names. Anyway, that's my answer.

Interesting to apply to yourself. And if you're going to have a kid, you can think about, you can put your considered names into there and see what you get. Yeah, we thought we were being clever with a name and it was not clever. Hey, you know, I think the reason, like if you look at your daughter's name, it was spiked right around her age, right? When she was born. Yeah. But I imagine that parents, we think of like other parents that we know to a

large degree right when you're having your a younger kid you're like okay well i don't know a lot of people with such and such name so that must be kind of unique i'll do that but it's it's unique for your generation but not for the coming one or something exactly so you got to look for some something that's unique for both so like my recommendation for a girl's name esther like no esther's around or the, well, there's some, but not very many. And it may be featured in a Jane, Jane Austen novel, given that it's like popular in the 1800s. Okay. There you go. Ethel. There's not going to be any other Ethels at the school.

Oh yeah. The long tail of Ethel is thin. Okay. Do you have anything extras for us? Nothing other than real-time follow-up. So here's what I got for you. I did a quick UV init and I got a very simple thing that pipeproject.tomahawk that just says a readme. It requires Python 3.13 and empty dependencies. And so I added requests, UV add, and then it added, did it add, that made it added a version. That's funky. Anyway, it added a version because of that. Oh, nice. And then it added the dependencies to just add requests or whatever. But it does not specify a build backend.

Weird. Because maybe you're not going to publish it. Maybe it's just, I don't know. Oh, right. Yeah. Right. Maybe it's just for you. You just want a little local package, like a monorepo sort of deal.

I don't know. Yeah. Also, you can, I think you can just push those up. Anyway, I wonder what happens. Anyway, this is what I found. This is what I've discovered by using the latest, nearly latest UV. Yeah. I'm having fun with UV.

Yeah, me too. Definitely, definitely. You know what else is fun? A joke. Yeah, let's do a joke. All right. This one celebrates, in quotes, getting a job or not getting a job. And it's entitled The Long Path to Rejection, in parentheses, for software developers.

So for a normal person, this might be really short. Send a CV, get rejected. And it has this graphic of stepping on a rake. Whack. It's like, no! And then for the software engineer, you got to do more. It shows them like kind of, this is freebri Brian, like kind of grinding a rail on a rake instead of a skateboard.

Send us a CV, interview with HR, interview with the developers, technical interview, whack, get rejected. This is great. He's doing a kickflip ollie down the stairs with a rake. And then get rejected. And then get rejected. I think that would be enough, wouldn't you? Yeah.

But somehow, somehow it is not yeah i never mastered the kickflip uli but i did master uh trying the kickflip uli and falling down and getting lots of blood from that i i mastered the amazing back landing when you go on the skateboard whoop and it shoots out in frontwards you just land flat on your back like oh yeah yourself uh last last thought of the show christian letterman says the default is set of tools for a project tunnel which you know defaults are powerful in terms of keeping people doing that yeah that might be the 50 maintain maintaining people and you know to be honest since uv came around i don't really think about backends much anymore um i just kind of use uv yeah yeah all right and marco out there says maybe this is a

podcast you could start instead of testing code skating code brain it's good yeah skater go and code skatership all right cool bye bye