Eric is the author of Python Crash Course, the Mostly Python newsletter, and the django-simple-deploy package. We talk about rewriting the Django deployment story, different hosting providers, and teaching Python & Django to newcomers.
This episode was brought to you by Buttondown, the easiest way to start, send, and grow your email newsletter. New customers can save 50% off their first year with Buttondown using the coupon code DJANGO.
Carlton Gibson 0:00
This episode is brought to you by Buttondown, the easiest way to start send and grow your email newsletter.
Hi. Welcome to another episode of Django chat. I'm Will Vincent, joined by Carlton Gibson, hello, Carlton.
Carlton Gibson 0:19
Hello Will.
Will Vincent 0:21
And we're very pleased to welcome back. Eric Mathis, author of Python Crash Course, creator of Django, simple deploy and some other things we'll talk about. Welcome back, Eric.
Eric Matthes 0:31
Thank you for having me.
Will Vincent 0:32
So I was thinking of you recently because I'm going to be going back to PyCon us for the first time in six years. And I remember back in 2019 the first time I met you in person was out of PyCon us, I think we we'd communicate online. And I remember then, I think it's still the case being shocked that you were not the celebrity there, because you then and now have the best selling, by far, Python book. And yet all these other, you know, mere mortals, we're getting all the attention. So I guess I'll tee that up. Tee that up as Do you still fly under the radar at these big conferences, even though I think a majority of people have learned from your book?
Eric Matthes 1:13
Yeah, I that's the phrase I use. I do feel like I fly under the radar, but it feels like a nice balance. People do know who I am. And so if people have stories to tell, they do find me, and I get to hear those stories of what the book has done for for people's lives, which is really nice.
Will Vincent 1:30
Yeah, well, maybe let's, let's start with that. So you're now in the third edition, I guess just a high level. How has it changed? Because when, when did you first publish it? It's been in print for a while now. I started
Eric Matthes 1:42
writing in 2013 the first edition came out in 2015 and the second edition came out and 2019 I believe. And there's a big I did a bunch of revisions for the second edition. So this, the second edition was very different than the first, not in terms of overall structure, but cleaned up a lot of the issues that people had found. And so third edition was really just mostly updating. Things were working, and so I kept most of it third edition, like knock on wood, things have continued to work well. And yeah, it's fully up to date, so it's been nice,
Will Vincent 2:23
yeah? Well, you're one of the few people who can relate. I just did the update to my Django for APIs book. And, you know, sometimes it's as much or more work to do the update as it is to do the the first one. Except, yes, it feels it's somehow less satisfying. I think, you know because, but it's you know, but I guess it's you wouldn't do it unless people cared about it and wanted to see it, right? So it's sort of, it's a little bit like a band playing their greatest hits. It's maybe not what you and your soul need, but you're happy to do it.
Eric Matthes 2:56
Yeah, Python and crash course has a big enough readership that it's, it ends up being really satisfying to do the revision. It's a lot more work than people realize. It's eight is six to 18 months of full time to 60 hour weeks.
Will Vincent 3:11
Yeah, it's just a lot. And yet you wrote the first edition, sorry, and yet you wrote the first edition in two years while working full time as a teacher, probably primarily in the summer, right? Like, I sometimes think the updates take longer than the initial thing did.
Eric Matthes 3:24
Yeah, yeah. I naively thought I could write it in the summer, draft it in the summer, and revise it during one school year, and it turned into two and a half years of most of my summers and early night, early mornings and late nights. And
Carlton Gibson 3:38
just at the end of those two and a half years, how are you feeling towards the project? Because it's those, this is those things that take a while to get out. They start to burn after a while.
Eric Matthes 3:48
You know, things got very quiet after it came out, because all that work was done. You had this printed book. So it's the space after
Carlton Gibson 3:56
it, you remember, rather than getting it over the finish line, yeah. Okay, nice. Yeah.
Will Vincent 4:01
Well, maybe it's, hopefully it's, we've talked about this, but, you know, you you are published through no starch, so you have a team, you know, helping with various things. I think for me, given I don't have a team, I often, you know, kind of want to, just like, burn my own books and I question my life by the time I get to the end. And you know, as much as like when I started, I think I'm gonna feel so great when I get the update out. By the time I do, I'm just like, I almost hope no one buys it so I don't have to do that again. So anyways, having a team maybe helps with that.
Eric Matthes 4:36
It definitely does. The Juice book is so much better for that team,
Carlton Gibson 4:42
just before we move on. I do want to say I bought the I bought the book for my kids. I put a third edition, sat there, and I've shown it to him. And I mean, like that, you know, this is what you need to pick up when you need they were like, can you teach me that I'm like, No, Eric, I had the same
Eric Matthes 4:55
conversation with my son. Can you teach me? Teach me how to do this? Yeah, I'll teach you. But like, here's. We're gonna do, yeah,
Will Vincent 5:01
right? Was that? I mean, right, as a book author, people want, want you to do a live or they want a video, and it's like, no, I put all the like, this is the curated, distilled, perfect version of it. Like, just go there. Why do you need me to muddle through my own, my own stuff? That's kind of how I feel about it. I mean, yeah,
Eric Matthes 5:19
yeah. You know, it's interesting in this AI era, people, people are still going to it. And I wasn't sure that that would happen, but people are still going to it, because, as most of us who use AI tools, know, they're only really useful if you know enough to make good use of them. And so people are. People are reading the book to get that foundation that gives them the background in order to make good use of of LLM assistance,
Carlton Gibson 5:47
it's quite important to have something that you know is reliable, right, right? There are very few and increasingly less sources that you can say, I know this is reliable. So Will's book, your book, like these stand out as exemplars of, yeah, actually, that's a trusted resource.
Will Vincent 6:04
Yeah? Well, I think you, you probably don't go right to paying you, you know, think, oh, like, I'll use the free ones, so I'll go to free resources online or free videos. And then I think with AI, it just sort of pushes out that it's not even, like, post tutorial hell. It's just that, like, Oh, my God. You know, I'm hearing different things. I just want a trusted voice. And then, you know, you reach for your wallet at some point, right? Whereas, I think those of us like to me like someone I trust does something, I'm like, Oh yeah, it's I'm saving money for sure, right? Right? Just because, and even if you're a student or someone else, people, maybe it's a stage of life. Like, I don't think it's just people in different countries with different purchasing power. Like, you have to come to that realization that your time and your energy is worth something and be sufficiently frustrated by what's out there before you say, Okay, where am I gonna go? Yeah, yes. So I wanted to ask you about your mostly Python newsletter on substack, which you've been doing for quite a while now, because that seems to be an area you can, you know, write new things rather than endlessly update your book. And in particular, I loved your Django series. I forget was it 1920 part series? Oh, gosh,
Eric Matthes 7:19
yes, 20 parts. Yeah, okay, that's great. Yeah. Is that mostly python.com? I started on sub stack, but I left sub stack because they're one of these free speech absolutists that isn't really free speech platforms, and so I'm working through ghost now.
Will Vincent 7:35
Well, Carlton, shout out to
Carlton Gibson 7:36
self hosting that, are you self hosting that are you using their hosted service, because it's I'm
Eric Matthes 7:42
using the hosted service. Very happy,
Carlton Gibson 7:44
yeah, yeah, and you're
Will Vincent 7:47
you're not charging, are you or are you charging? You're not i don't think
Eric Matthes 7:51
i There are paid subscriptions, and what I'm doing for free subscribers is that most of the posts are actually free when they go out. But then I do some series, and typically I've done this series where the series is available to paid subscribers for a period of six weeks, and then it gets released to everybody.
Carlton Gibson 8:16
And how do you find that setup working?
Eric Matthes 8:20
You know, I stalled. The growth of paid subscribers stalled. When I did this switch to to ghost, I also stopped. I also made all the posts free for a while because I didn't want to lose people in that transition. But our lives, my family's life, has been all over the place for the last year and a half. We moved from Alaska to North Carolina, and that was a much more drawn out move than anticipated, life under a hurricane and all kinds of things. So I have focused on making sure the writing is consistent and high quality. And I'll come back to you focus on whether people are paying or not.
Will Vincent 8:59
Yeah. Yeah. I mean, I think, I think we featured, I would have featured, like, every single one of them in the Django news newsletter, because especially, especially your Django series was just fantastic. I think we, we featured a bunch of them. I was like, I can't do it every week, but Right. But I definitely recommend people, you know, starting from scratch. Like, if they put the time in to do that, they're going to be so far ahead of other resources out there, you know, yeah,
Eric Matthes 9:26
for people unfamiliar with it, I started the newsletter because I have this book, but the book is self contained, and, you know, it's a thing I work on for six to 18 months once every three to four years. And then what do I do? So I wanted to write more regularly, and I wanted to write about a wider variety of topics than just an introduction to Python. And so that it was a weekly newsletter for the first couple of years, and I just moved it to bi weekly, because weekly just got unsustainable after two years, bi weekly feels very nice. I really enjoyed the writing, and I can make a. Morning or a day every two weeks to focus on writing the Django from first principles series comes out of a long series, going back to Carlton's talk about serving a Django project from one file and you were building on prior work as well. But every time I've heard of these micro Django projects. I've thought like, Ooh, this is a good foundation for teaching people Django, because one of the things that people get confused about when they first learn Django is they run start project, and suddenly they have 11, 1317, files that are trying to make sense of all that. And a lot of if you're teaching somebody Django, a lot of your work is telling them go to this file, then go to that file. And so it's really nice to just start with a very simple file, single file, and then only expand out to other files as needed as the project grows. So that's why the series expanded out to 20 posts.
Carlton Gibson 10:57
I think that's a lovely way of teaching the framework like the bottom line is, we're turning web web requests into web responses, and that gets hidden quite a lot, you know, because you where do you begin? You begin by importing a list view, and, you know, just defining the model on it, and then suddenly there's a template, and suddenly it all appears. You say, Hang on. An awful lot has happened. There was, if you go back to just there's a view, it takes in a request, it returns a response. There's the handler that you know is dispatching the request for you. There's no middleware. There's no anything. It's easy to see what's going on. Then you can bolt on middleware, bolt on, you know, whatever you want. I think it helps you to grasp what's going on under the hood, so to
Eric Matthes 11:37
speak, right? And then when you've reached the end, wow. Okay, this is why all those files were created by start project, and you don't need to go through that process again. You just run start project, and you know where all the pieces are and why they are organized that way. I may turn that into a mini ebook. I might take on Will's burden, and
Will Vincent 11:59
just make sure you update it every eight months, and as soon as you update it, get an email from someone saying, oh, like, when's the next update coming? Or, you know, psycho PG changed. Or, Yes, I definitely greatly envy the release cadence of your Python book, but yeah, that's the version of frameworks.
Eric Matthes 12:20
There's a lot of work there that that's invisible around selecting libraries and approaches that are likely to be stable for a period of three to five years. Yeah.
Will Vincent 12:30
Well, I mean, one of the things that I've I've changed in my books over the years is how I handle deployment, and that leads into probably the rest of our discussion. That's
Carlton Gibson 12:39
That was the smoothest change ever.
Eric Matthes 12:42
You like to talk about deployment?
Will Vincent 12:43
I like to complain about deployment. So I was gonna say that I have, when I first, my first edition of the beginners book, I was trying to mimic, there was some rails book where they just like, boom, like first, first chapter. Basically, you deployed something. And so I really want to demystify and of course, it's a horribly insecure thing, and Django makes it harder than it needs to be. And Heroku was designed for Rails initially, not Django, but it's possible. But I have increasingly so the most recent version of my beginner's book, and the beginner's book, I've moved deployment completely to the end because I heard from enough people I used to have progressively complex, more complex projects. I think there's five, and then I would have progressively more complex deployments. So the idea was like, just get something up and then, you know, show how you can button it down and, you know, lock up allowed hosts and all these other things. But I've had enough people and teachers who've used it in universities say that they just skipped the deployment stuff because it overwhelmed the students, or now that there isn't a great free option, the students didn't have the money for it, though, presumably they have the money for their degree and to buy the book. So all of which is a lead up to say deployment is a challenge, and probably one of the three or five things that Django could get better. And I know you have a Django section in your Python crash course book, and have dealt with this pain from readers a lot, so I'm done. That's a setup we've we talked about before, but there's a lot of new stuff around Django. Simple deploy, so go, yeah.
Eric Matthes 14:22
So I was looking forward to coming back and speaking with you both about this project, Tango, simple deploy. And the reason for coming back at this time is I just made the 1.0 stable release people who can't see confidence. I'll put a sound effect in there. Yeah, yeah. And so, yeah, it came out of teaching people Django deployment for a long time and doing my own deployments. And every time I've done a deployment, I have noticed how much time I spend reading platform documentation, whether it's Heroku, fly, platform, sh, DigitalOcean. Um, we all spend unless, unless you work for a Django consultancy where you deploy different people's projects every week, I think most of us spend a fair bit of time poring over the documentation for these platforms, not to tune our deployments, but just to get that initial deployment working. And so the core idea of that I've had for a long time was to ask that question, how can we automate this process from the Django side, rather than from the platform side? Because any platform specific solution is only going to be useful to the people who use that platform, and also only as long as that platform is mindful enough to maintain that that tool. So Django symbol deploy is the tagline is deployment for Djangonauts with deadlines.
Carlton Gibson 15:52
Well, that's all of us, right?
Eric Matthes 15:56
I think that is rewriting the Django deployment story. Jacob deployment has been seen as difficult and fraught with cliffs that you can fall off of for a long time, and I think this project rewrites that story. So in short, when you install Django simple deploy, pip install Django simple deploy, or UV pip install Django simple deploy, it adds a Management Command, one command, deploy. And then if you want to deploy to fly.io you install the fly.io plug in. So it's a plug in based system. And then you run, you add Django sample, deploy to installed apps. Run one command, manage.py deploy Dash. Dash, automate all and it creates a project on fly for you and pushes your project and opens it in a new browser. And so you don't have to you need the fly CLI installed and you need an active account on fly, but you don't need to read their docs. You don't need to go create a project. Your project appears running in your browser on a remote server, as it does locally on your system. Yeah, it's amazing. Yeah.
Carlton Gibson 17:15
So can I? Can I just knock one up in the air for you myself? Eric, one of the reasons why the jacket. So people often like the Django docs, need a better deployment story, because they've got some, you know, very, very minimal deployment docs. But more or less, they've remained diagnostic about deployment options. And the reason it's been there's just no way of maintaining that. There's too many options, too complex, too likely to change and go out a day, and it's just not something that we could maintain in the in the Django docs themselves. So right? You mentioned a plug in system for Django, simple toys, that that's the the secret to being able to maintain multiple options. You'd say,
Eric Matthes 17:56
That's right, and that's that's why it took so long to reach 1.0 because when I first built a project like proof of concept, I think was 2019 2020, ish, and it started just as a Heroku build back. And so it only worked Heroku, and it ran on Heroku end. And then I had that shower thought of, oh, how could I do that work in the Django world instead of on Heroku servers? And a management command is the answer to that, because you can run a Management Command, and now you're running on the user's local system. So you can inspect their system, you can inspect their project, you can see what what platform, CLI s, they have installed, and that kind of thing. And so I rewrote that Heroku deployment script has a Management Command, and then I said, Okay, can I, can I generalize this? And so I built in support for, I think, flat out, IO next. And then I had, I wanted to do one more. Because if you can do something, if you can support three platforms, then you've probably solved the general generalizability problem. And so the pre 1.0 version of Django, simple deploy, supported deployments to Heroku, fly.io and platform.sh but it was all one big, one big project. And so yeah, you could already see the maintenance problem, particularly if you're going to try to continue expanding support for different platforms. So the plugin the plugin system, is the solution to that. So I implemented an internal plugin model where each of these platform specific code bases were their own plugin, and then I extracted those plugins out into separate repositories. And so now there's it's a nice I think of it as a what do I call it? A thin tool, thin library, and fat plugins. And
Carlton Gibson 19:50
probably the fat plugins are better documentation for these platforms than the platforms have themselves. In some cases. Yeah,
Eric Matthes 19:56
I want to be careful when I say you don't. Need to go to the platform's documentation. You don't need to go, I keep using Fly. Fly is my go to example when talking about this. So if you want to do your first deployment to fly, you don't need to go pour over the fly documentation to get your initial deployment working. If you're going to maintain a project on fly, you need to read their documentation. Need to understand how their deployments work. But the point is, you can start that learning with a working project, so you don't have to go pour over their documentation. Find the right parts, find the relevant Django parts, hope they're up to date, try to get everything right, get a working deployment, and then move on. You start all that with a working deployment. One of the really, one of the really cool things about this is I mentioned that manage.py deploy Dash. Dash, automate all that's the fully automated mode A lot of people. So that creates a project on you, on fly for you, configures your project, locally, commits your changes, pushes your changes to fly servers, and then opens your project in a new browser tab. There are people who love that. There are people who don't like the idea of a library making a commit on your behalf.
Will Vincent 21:17
Those are dinosaurs. The agents are just all we're going to do is review PRs, PRs now,
Eric Matthes 21:22
so there's a configuration only mode where you create an empty project on fly. You run manage.py deploy, without the automate all flag. It configures your project for deployment to fly, but it doesn't make a commit. And so after running manage.py deploy, you get to review the changes when you're satisfied with how it has modified your project for deployment. Then you run, you make your commit, and then you run fly deploy. So you run the platforms deploy command, and so it adds just a few more steps. But either of these processes is really nice, because it, like Carlton, you just said, is a nice documentation for the platform. All the platform specific configuration is contained in one git commit. Yeah, yeah. Or you can just run git diff and you see exactly what changes were needed to make a deployment to the platform. Now,
Will Vincent 22:21
how have your readers responded to this? Right? Because I know part of this came around the frustration we both had, around changing, updating our books, around deployment, things. What feedback do you get from readers? Because I know you have a lot of readers, so I do,
Eric Matthes 22:37
but I have it's not in the third edition. So the third just on your Oh, it's just on your website. Then, yeah, third edition of Python Crash Course came out in 2021 and I was really just kind of getting this proof of concept done.
Will Vincent 22:50
So fourth edition, fourth edition, you'll just slide a sentence in there, and then it'll just, yeah,
Eric Matthes 22:55
and it's, it's fantastic, because it's a nice abstraction layer, you know. I Since 2015 I have watched the platform that I target Heroku for the first edition and second edition. Currently, the third edition walks readers through a deployment two platform.sh, and so I've just watched those platforms for 10 years with my fingers crossed that they don't change their process in a way that breaks deployment for the book. And so this this project, Django simple deploy, also solved that problem for authors, content creators. If you've walked your readers through deployment using Django simple deploy, as long as one person updates the plugin when the platform changes their process, all your tutorials still work.
Carlton Gibson 23:39
Can I ask about the plugin, Sarah, because I think, sure, in Django, we've got third party apps. Traditionally, add something to installed apps, maybe add a middleware, and then DjangoCon us last year, Simon Willison gave a great talk about a new plugin system that, you know, I can't remember what he called it, but DJ plugins or something, I don't know. And it's, but it's, it's, it's like, you don't have to make a kind of cut, you don't have to make a change in code. It will look in your plug in Install Plugins at runtime. When you fire it up and like, automatically load the ones that are there. How's the plugin system for simple deploy work.
Eric Matthes 24:19
You know, there are some things about this project that that make it easier to deal with plugins than some others. One thing is there's, there's no real back and forth. So you, when you run manage.py, deploy, there's code in the core library Django, simple deploy that inspects your system. Are you on Windows, Linux, Mac, OS, what requirements system, are you using? It also inspect your project. Do you have already have a platform specific settings, block, that kind of stuff. How are you structured? And once it's done, it doesn't validation, if it finds any. Using the deployment might not work, then it bails before making any platform specific changes. But once it's done all that inspection, then it just hands off. All the rest of the work is done by the plugin. So there's, there's no back and forth. We're not just, you know, calling some plugins, right? It's, it's done through a hook, but it really just the core Django sample deploy tool passes a config object to the plugin, and the plugin, when it first loads, sends a config object to core, and so the core knows what platform is being targeted, and the plugin knows anything it needs to about the system in the project, and it works quite well. It's a pretty it's kind of like an API boundary. You define that, define that boundary between the core tool and the plugins, and then just define a clean interface.
Carlton Gibson 25:57
So what you're really hoping for now is someone to contribute a kind of a plug in that you didn't write. That's the Yes. Simon Willis had said this. The mark of success for plug in system is when you get one that you
Eric Matthes 26:09
didn't write. Yeah. And so I've done sprints for this project at several djangocons in the last few pycons, and I've consistently got gotten 10 to 15 people at my table. People are really interested in the project, and some people have really helped move the project forward. I lose names when I'm in these these conversations, but some Yeah, someone else, I'll throw two neighbors, I believe is either Andrew humchar or Josh Thomas. One of them, they've both contributed and helped me talk through some things. One of them made a fork and just did a super simple here's how a plugin interface might look. And so I just I looked at that, and that's how I implemented the initial plugin model. So I'm going to PyCon in May, and I'll stay for a couple days of sprints. And so when I do sprints this year, the focus is going to be, who wants to write a plugin?
Carlton Gibson 27:13
This episode is brought to you by button down. That's buttondown.com. Email software for developers like you, there are hundreds of email marketing software services out there, and they will pretty much offer the same thing, collect and clean addresses, send out broadcasts or drip campaigns, get analytics so you can see what's resonating and what's not. Button down is designed to hook into the tools that you already care about, everything from static site generators like Jekyll or Hugo to payment platforms like Stripe and memberful, you can hook your site up to button down with just a form element or a simple REST call write emails in Markdown and then get on with the actual work you're supposed to do. New Customers can save 50% off their first year with button down using the coupon code Django, and if you email support, they'll white glove migrate your existing subscribers and archives for free.
Eric Matthes 27:37
I think I might do an open space about it as well. Because the nice thing about that with spaces is during the conference, and everybody's still there.
Carlton Gibson 27:45
You know, from a sort of Django perspective, I'm really excited Django, simple deploys. One of the most exciting projects for me is because it's been one of the mass, the biggest pain points, and it's like, clearly a solution that we can get behind as a community. And if people have got their own opinions. That's fine. Just fork the nearest plug in that looks like yours and adapt it to what you need. But it's something that we can have a consistent story to begin as to turn up. How do I deploy my Django project? Use Django symbol deploy,
Eric Matthes 28:14
right? And so it's one of these projects. I mean, I say this with humility. There are projects like pi test that I really respect, because pi test is clearly focused on professional projects, complex projects. But I've also found it it's easier to teach beginners testing using PI test than it is the standard Library's unit test. Pi test is a is a library that is so well implemented, so well thought out, that is the best thing for beginners and is the best thing for many, or most professionals. And so simple deploy starts out seeing looking like a product that's just for people who don't already know deployment, but the more you poke at it, the more it becomes just to a tool for it's a more efficient workflow for people who already know deployment for a platform. And it is a tool for authors. It's a tool for content creators. It helps platform providers. And platform providers don't want their documentation to go stale. They want Django developers to be able to consistently push their projects to their platform they're struggling with, you know, keeping their stuff up to date, just like we do. So it's a tool with lots of use cases,
Carlton Gibson 29:30
I imagine, for a platform as well. There's it's much easier to allocate the engineering time to fix an issue on a plugin for one repo than it is to allocate the more nebulous time of update the docs to make sure, well, I don't know what I need. Whereas there's an issue that says the deployment for Platform A is broken. Fix it here. An engineer can fix that in the morning,
Eric Matthes 29:52
right platform.sh does mention Django simply deploy on their deployment Docs as one of the options for how to. Get a working jingle project on their platform. So
Carlton Gibson 30:03
world domination is only weeks away,
Eric Matthes 30:06
maybe months, but yeah, surely, yeah. You know, the plug in conversation is really interesting. And so I talk about fly platform. Let's teach and Heroku initially, because it's easier to start talking about platform as a service providers, but with after the 1.0 release, one of the things I was most excited about was writing a plugin that targets a VPS, because I have deployed to past providers like Heroku, all of these, and I've also done deployments to Digital Ocean, and I like having the option to do that range of deployments. So in the post 1.0 world, I really wanted to see, like, can I write a plugin that deploys to a VPS? And so I thought I'd have to, like, build some abstraction. Like, okay, I'll target Digital Ocean. I'll extract out all the, like, generic VPS utility functions, and then somebody else can write, like, a DSD, Linode or Hetzner, O, V, H. And I think it was Tim Schilling point out, like, I think one solution is going to work for all of these. And it wasn't until I had it working, I was like, Oh my gosh. I the plugin was initially called DSD dash Digital Ocean, and I realized it doesn't know anything about the fact that it's deploying to digital ocean. You install,
Carlton Gibson 31:36
you give it is the SSH, yeah, you just say, there you go he
Eric Matthes 31:41
set two environment variables, IP address and your Your initial password for SSH, and then it does the same thing it does for other platforms. It inspects your system, inspects your project, and does everything through that sh connection. The plugin does everything through the SSH connection. It's a lot harder to write that plugin than than it is for the past providers, because it's no longer just configure the project according to their docs and push it. It's Oh gosh, we have a bear for you. For people who aren't familiar, VPS is a virtual private server, and so if you go to any of these VPS providers, DigitalOcean, Linode, hetner, o, V, H, any number of them, what you get is a bear server. So I typically use in Ubuntu instances, because what I've used locally, you can choose Debian any number of of images. So you basically get a bare server, and you have to do all the configuration. And so the plugin, I did rename it, it's called DSD dash VPS, and it's in the djinko Simple deploy organization when you install so if you wanted to try this, you have your project that works locally. You don't even have to install Django simple deploy, because Django simple deploy is a dependency of the plugins. So you have your project that works locally, and you install pip install DSD, VPS, and that installs simple deploy. You do add Django simple deploy to your installed apps, because that's where your management command is coming from. And now you run you have to create a VPS instance on your provider and Digital Ocean, that's called a droplet. Doesn't matter which platform you just create an instance, and you you set those two environment variables for your your server's IP address and the password you chose for SSH connection, and then you run simple deploy. I'm sorry. You run manage.py, deploy, Dash. Dash, automate all and it does a magic it inspects your system, inspects your project, and now it calls out and it creates a new non root user on the server. It upgrades a server, reboots as many times as needed, installs Python this version, installs it through UV, which is nice. And then one of the interesting parts is you don't have a deploy command from a past provider. And so I ended up solving this by writing a serve project.sh, script, which activates the virtual environment system environment variables and also does some configuration to set up. I'm using gun acorn, if I'm saying that, right? And caddy, and so it sets up those two as services on the server so that serve project.sh. Starts those two services. And again, in the end, you don't need to know all that right away. It just pops up your project in a browser. It's it's really. Seen that project through an IP address over HTTP, not HTTPS, because I think you need a domain name to use HTTPS.
Carlton Gibson 35:13
Well, you'd have to sign the certificate and all sorts of complexities otherwise. Yeah,
Eric Matthes 35:18
so unless you're doing a domain based deployment, right away, you're going to get some kind of warning for your browser that this is a self signed certificate or HTTP. But if you're deploying to VPS, that's not an issue, because you're that's part of your your process. The bigger picture, it does how many people have deployed to a VPS by following digital oceans Django on Ubuntu. So instead of reading that whole, that whole tutorial, which sends you out to other tutorials of how to set up your server, how to set up a firewall, how to deploy Dingo, it does all that for you. I basically followed that, that guide, and then updated it with UV updated with caddy instead of Nginx. But I I ended up with this plugin, DSD, VPS, and realized it now works. We can't just say Django simple deploy supports fly platform, sh and Heroku, and if I it supports those three and every VPS host out there,
Speaker 1 36:25
yeah, which is fantastic, yeah, yeah,
Will Vincent 36:29
well, Carlton, I don't know if this gives you PTSD, but you, you spend some time fiddling with VPs deployments, you
Carlton Gibson 36:36
know. And I still, this is exactly how I deploy. Still. I mean, I, you know, I use Ansible instead of a shell script. I do, you know, various bits and bobs, but absolutely, this is so you know, this is something I was looking at, spoke to Eric about, was my button project, which is currently on pause. I was going to try and ship that when I stepped down as a fellow but my son was ill, so I missed my window there, but I'll pick that up. But watching Eric. I've been cheering him along from the from the sidelines here, going, yes. Eric, yes, yes, yes, yes, yes, yes, because this is sort of like from the deployment side of it. This is the holy grail. It's like Yes, something which wraps wraps it up, and you can take the plug in, you can fork it, you can customize it. You can to make your tweaks that you need to make it yours. But that basic spin up your VPS provision it get your projects or your code in place on the project, and get it running, that's what we need. Then that's to have that in place is so super so as I've been watching Eric doing this, I've been like, oh, but that means I can just focus in on the monitoring side. So for my own tools, and that's much more exciting for me now, because I did get exactly this kind of stress about all the options and all the configuration channels you could go down and all. It's massively complex. And so, you know, hat tip to Europe for getting it wrapped up.
Eric Matthes 37:59
Yeah, you know, at the time of this recording, that DSD, dash, VPS has not been released. It is on GitHub. I haven't pushed it to Pypi quite yet. It's only working on Mac OS at the moment, this morning, I was just cleaning up integration tests, and the next step is to write an end to end test. But that's that's fairly straightforward with every one of these plugins. The difficult work has been getting the initial deployment to work, and once that works, the rest of the piece to fall into place completely.
I'm not an expert on deploying to a VPS. I've done it. It's worked for my very small projects. They're long running, they're important, but they don't have high numbers of users. And so I just get something that works, that works for me for a long time. One of the nice things about these plugins is they become a place to use our shared collective wisdom. Yeah. And so we have people like, you know Jeff, who works for rev, says Peter Baumgartner worked for Lincoln loop, or founded Lincoln loop. He released a project, I think, two years ago called Django production, Django dash production. And the goal there was, I think it's a library you can use and you run a command, and it modifies your settings to use, like his best experience around settings at work in production. And so now we can go back and look at projects like that and blog posts, um, and take all this, like hard earned experience and dump that into the plugin. And so from that point, if we do that, from that point forward, everybody who uses simple deploy to run their initial deployment gains the benefit of that, that collective wisdom. And it really feels like, you know, I've watched people who have really good experience, deep experience with deployment, and there's, there's no real way for them to to get that out to everybody in a way that it gets used consistently. And so this feels. Really good, yeah,
Speaker 1 40:01
no, and it's exactly exciting for those reasons. I want, I
Carlton Gibson 40:06
wanted to ask you about the sort of the second deploy. So I, you know, I Django deploy Dash. Dash, automate all and, you know, my new server and my provisioning and and then I make some changes. I, you know, I commit my new changes. I want to deploy again. I just run Django deploy.
Eric Matthes 40:26
Oh, okay, let me take a step back. So when people want to make their own plugin, there's a better story than, you know, fork the existing plugin and modify it. I made a plugin called DSD plugin template. Or I shouldn't say a plugin is a project, and so it's just a repository. It's in the Django simple deploy organization. And so there's documentation for this in the Django template docs, under the plugins section, if you want to make a new plugin. So Carlton, no, Alexey will, will, like, Will's the Docker guy, right?
Will Vincent 41:00
Well, I'm, I've been, I've been moved away by Carlton, but yes, I still have a book on it and I, but yeah, I had my my Learn django.com site was all doctor. If
Carlton Gibson 41:10
you forgotten the golden rule, don't do what Carlton does, just
Will Vincent 41:13
because with a healthy dose of, you know, caution and, you know anxiety. I have followed Carlton down this path, but I still am familiar with Docker a little bit,
Eric Matthes 41:28
all right. So will takes Carlton's advice to not follow him too closely to heart, and says, I'm gonna back all in on Docker. And will wants to write a plugin called DSD VPS Docker. So his best approach is probably not to just fork my plugin. His best approach is to download, not clone, download this DST, VPS plugin template, sorry, DSD plugin template, and it gives you, it'll ask you, like, four questions, what's your target platform? Are you supporting automated, the fully automated approach? What informal name do you want for it? And then it gives you a plug in with the right names in the right places, and it gives you tests. And so you can run pi test right off the bat, and you have a working set of tests for your plugin. So all the all the plumbing is there. And so you get to drop into just the part of the plugin that actually does the the configuration and setup. And so where I'm writing this serve project.sh will would write a Docker file. And so it's nice you get a clean, clean Plug, plug in to start with. And so you're just focusing on, like your expertise, which is really nice,
Carlton Gibson 42:54
right? But I'm going to come back to my my question about the second deploy, because the first deploy you have to provision the server. But the second deploy, you just kind of well the second time, when you update your running Django application, you have to refresh the code for files somehow, either a pull or a push or some somehow, you have to get your new code on the server. You have to update your virtual environment. You perhaps run your migrations, you create static files, and then you reload your service, your service which is running the application. I once, I haven't looked into it, so I don't know. How do you, how do you handle the fact, how do you, how do you handle the state change there of, oh, no, I actually need to do the whole provisioning thing. Versus, no, no, all of that's in place, and I can just whiz through with the with the much quicker step of redeploy.
Eric Matthes 43:42
Yeah. So a fun question for this project has been, what exactly does the word simple mean? What are the boundaries simple to who? Yes, so simple for the end user. So good question. It should be simple for the end user to do their initial deployment. It should also take a step back. There's a section of the docs that talks about what it takes to write your own plugin and the things you need to think about and the questions you need to answer before writing any code. One of the questions is, can, can deployment to the target platform be fully automated? One of the other questions is, what's the concluding message you're going to give to people when this deploy command finishes? And so where what it looks like? There's a.pi file called deploy messages.py, and there's a success message. And so you have to write your success message to people. So they run, manage.py, deploy that judge, automate all say, and their deployment pops up in the browser. And so that's their first appointment. And Carlton's question, okay, they make project changes to their project locally. How do they push that next change? So in your success message, you need to be able to answer that question. So the past providers, that's fairly straightforward. Somebody push it to fly. The Fly success message is pretty short. It says deployment should be successful. You should have seen your your project pop up in a new browser. If you didn't, here's the URL you can go to to make your to make changes to your project, make your changes locally, make a commit, rerun, fly, deploy. Yeah, and that's about as simple as it is for most of the past providers. For a VPS, we have to answer that question, right? Good. So I haven't written that that success message yet, but I think for my, my approach of kind of corn caddy as services I did set up a git push. So I think that, I think the second deployment is make your changes, commit them, run kit push, and then I'm not quite sure how to restart the services. And that's a question, you know, I'm not sure how much responsibility I'm going to take in simple deploy for that second deployment. That's not the main goal. I need to know that people can do a second deployment. But when we're talking VPS, is, it's kind of a bigger open question. The goal is, yeah, I have, I have felt like I'm standing in the shoes of the people who started all these past providers by writing this serve product.sh, and writing a script for it, like they must have gone through these same processes and answered the same questions. So I might just put a small script on their their server that says, like, you know, run this sh command to restart all those services. Or I might say, you know what that's that's too varied to do, and the only promise for this project might end up being, we got you your initial deployment. Here's the kinds of things you're going to need to do to maintain it. Yeah, and
Carlton Gibson 47:05
when you talk about getting gathering the collective wisdom of the Django community, well, you know, people can put input there as to options. People can blog about, well, you know, this is what I do next, and opinions will fall Yes,
Eric Matthes 47:22
can I ask if I asked Sorry? Go ahead. Go ahead. Well, as Carlton saw this yesterday, I posted a question on mastodon. So I said, the all the the past focused plugins have two modes. There's the automated automate all mode, where it does everything for you, including making your commits and pushing your project. And it has a configuration only mode where it does a configuration which is the hard part. You make the commit which is easy, and you run the platform's deploy command, which is easy, should be easy with a VPS. It's much. I have really struggled to come up with a configuration only mode, because if you're starting with a bare server, there's a bunch you need to do to update the server, create a non root user, reboot it as needed, install Python, certainly, maybe some other things you need to start these services at some point you need to configure, like, an SSH key pair for, forget push, if that's how you're handling code. And so configuration only mode feels like, ooh, it's not just one step for configuration. It might be like, I don't know if I want to do like, manage.py deploy dash, dash configure remote, manage.py dash, dash configure local. Manage.py dot dash, push. So, you know, I'm open to, I mean, people writing their own plugins can make this as complicated as they want. Like, you can re recreate the entire CLI for OCO if you want. I don't want to do that. It doesn't need to stay super simple. It should just be clear and simple for the end user, yeah.
Carlton Gibson 49:14
And I think with Yeah, that's a nice way of thinking about it. Is the scope, if you give an example, that's that's sufficient. I always felt with VPs, is the sort of two steps. Okay, you first of all, you need to provision your VPS with your provider. So, okay, that's step zero. But then step one is get the web server installed, get the, you know, whatever other dependencies are installed. And then Step two was deploy your application, which was code, virtual environment, you know, migrations, static files, etc, right? And running it,
Speaker 1 49:48
if you just have one flag, well, do you just go to Step Well, step zero, before step one or after step one, right? And
Eric Matthes 49:58
I haven't started out yet, you know, with. The with the past providers, it's very clear, here's your local work, here's your remote work. Yeah, with a VPS, I haven't quite sorted out if there's more back and forth that has to happen. The one other big thing that's different about supporting a VPS is you need to do some things outside of the local project. So for setting up a git push, I believe you need to configure those SSH keys outside of the local project, and so as soon as you're writing, writing anything to a location outside of the user's local project, they can no longer undo that with Git, yeah. And so you know, one of the original promises of the project is all changes made in a single commit. You can improve them or roll them back as needed. This is a little different, but again, to throw all that up in the air, I mean, somebody who's looking for a tool that automates deployment to a VPS and saves them all that work, probably want all that done. You probably want, like your project, running in that VPS, if you're starting from pair VPS, I'm just thinking
Will Vincent 51:04
one of the things, one of the reasons why I, I started with Heroku, and then I switched to fly, and then I've gone back to Heroku, is because Heroku is one of the very few that still supports git deployments, as opposed to spinning up, you know, a Docker container. And of course, it sort of does that behind the scenes. But one of the challenges I found with fly is basically I had to give people kind of a Docker file or Doc, you know. And I really disliked having to say there's this thing called Docker and containerization, but don't worry about it. Just use this thing, trust me, and we're not going to get into it, but that seems, you know, that is the, the new way that everyone's doing it behind the scenes. And so I guess I wonder for you, when you with the Heroku support, is that be using the Git based, or are you also using a Docker, Docker kind of file thing with James simple, yeah, for Heroku,
Eric Matthes 51:59
the Heroku plugin is git based, okay,
Will Vincent 52:03
but the other ones you are not right. You need to generate. Well, I guess this has changed, to be fair, like, and I was working a little bit with fly at the time, they were automating a little bit, but it's still ultimately, like I would have, you need to, and maybe I'm dating myself, but you needed to, the yeah, there's the deployment was different. Like, you could get ignore some things, and Heroku wouldn't have it, but, like, fly would still see it unless you added a, you know, Docker ignore file. And so, you know, it would create a Docker, a Docker file for you. But if you didn't know to ignore it, then. Anyways, I just found all
Eric Matthes 52:42
of that frustrated things like your virtual environment pushed to fly.
Will Vincent 52:46
Yeah, right. And that was relevant, because at the time, I was trying to step through progressively more complex deployments, and yet it just felt very hand wavy. I didn't really see a nice progression there, other than being like, just do these things. Like, okay, yeah, we're gonna do Docker. Don't worry about that. You need a docker. Ignore file. Don't worry about that. And then again, at the time, fly was going undergoing a lot of changes to make it better, but it meant that the normal cycle of these deployment places, you know, changing their docs, was even more accelerated and but, yeah, hopefully it's more stable now it probably is. Yeah.
Eric Matthes 53:22
I mean, I I've had the same frustrations that will has had. So in Python Crash Course, chapter 20, the last chapter of the book, The last section of that chapter is about deployment, and it's the one part of the book where I felt that I wasn't really teaching people things. I was telling them to write this file, do this, trust me,
Will Vincent 53:38
the whole book, the whole book, and then you're like, just do it this way. Yeah.
Eric Matthes 53:42
And so Django, simple deploy, I've had one person criticize the project, and that was somebody who knows deployment way better than I do, and probably better than most of us. And their only complaint was, oh, you can't automate it all. People won't learn how this all works. And I think I could have another I think I could have another dinner with that, that person. How could
Will Vincent 54:04
you teach Python without first teaching C and assembly and, you know, how dare you
Eric Matthes 54:09
go to the beach and melt some sand so jingle, simple deploy really changes the way you teach that. Because if you wanted to use simple deploy to target fly in your book, you could have people install simple deploy, the fly plugin, run manage.py to deploy dash, automate all if you want, you'd probably do the configuration only route so they make their commit and run their platform command, but then you're free to say The tool made a Docker file for you. You don't have to show the Docker file, so if that changes, you're not worried about, like, does the text of the Docker file in your book match the current one? And so you can talk about what a Docker file is and what it does, and what parts people should look at, look for, and not worry if there's a few more sections, or some sections are locked down. Yeah. It
Carlton Gibson 55:00
always felt to me like deployment, a complex deployment, any deployments complex, they just are. This is one of the problems, but deployments kind of like a grandfather clock or something, and if it's not moving, it's really difficult to work out what all any of the bits do, because it's massively complex, and you can't really see but if you get it moving, and you can watch it ticking, and you can watch the cogs go around, and you can watch the hands move, and you can watch the little cuckoo come out, if it's got one of those, you can learn you can say, oh, that bit does this and that, you know, I think that's really useful,
Eric Matthes 55:32
yeah. So I'll use will as the subject for this, but it goes for anybody writing Django tutorials. So one of the reasons that will would probably choose a configuration only approach for a book is you could tell your users, install, simple deploy, install the fly, plug in, run, manage, apply, pi, deploy without the automate all. And you can tell your readers now run git diff. Now look at the changes were made, and you can point them to some broad changes to look for, but again, not getting lost in the weeds that tend to change. And it's so it's a tool that simplifies things, but also, like, if you use it right, deepens people's understanding in a much better way. Because deepen, deepening people's understanding of something that works is way easier than trying to get people to understand something that they made. One typo that makes everything fall apart. There's
Carlton Gibson 56:23
a semicolon missing.
Eric Matthes 56:27
I was gonna say there's one other point to this. And I think you guys can see that like this project has all these subtleties to it. One of the reasons, okay, one pattern we see in platforms deployment Docs is they give you a very simple Docker file. They give you a very simple proc file, or very simple set of changes to make to your settings file. And what I see them all doing is giving the minimal set of changes, because every additional change you make ask the user to make to their project, the more changes they have a failed deployment, and no platform wants people to fail their initial deployments, because you'll walk away if those files and changes are being made for you, being written for you and made for you. There's no need to simplify it. And so when we're talking about a Docker based deployment, I had this interaction with Jeff triplet, where I, you know, my Docker file for fly was copied from fly documentation, and Jeff let it said, Hey, here's a way to make it much lighter. And, like, cool, okay. And so you can also add sections. So, you know, I go to Peter bonegardners, James of production, there are settings changes that he's making in that project that would be beneficial to a good number of people. And we can just dump those into the final because it doesn't matter if it's 30 lines of modified settings, if you're not having to take tell people to type it or copy it or
Will Vincent 57:58
Yeah, yeah. And just to make this even more similar, and to give Jeff a shout out, not that he needs it, but, I mean, Jeff basically taught me Docker for the Jenga professionals book. And then when I was I spent far too much time with fly but it ended up that I consulted with them and wrote the initial docs and helped update the Docker file and a whole bunch of things. And a lot of that was just sort of showing it to Jeff and being like, what do you think of this? And he always had improvements. So I would suspect that the still the Docker file that's in there might have been one that that Jeff wrote, because the initial version they had was something that an engineer who knew what they were doing but didn't know Django, Python, clearly, just looking at it, this was completely unoptimized. And so, right, yeah, Jeff and I did some PRs on that. And, yeah, it must be, must be odd for Jeff to be in that situation, sort of like a grandfather like, Oh, look at, you know, but, but, like, how do people unless you have this grandfather clock? And I love that analogy, Carlton, like, how do you know how to really tweak or fiddle these things and see the results like That's absolutely right. I hadn't thought about quite like that. Without it up and running, it's difficult to to see how these changes matter and to even use them. And I guess many people, they're hesitant to spend to deploy something and pay that cost, at learning costs because you do need to spend a little bit to have it going, but it, you know, nothing like learning on the job, right? Nothing like learning on your own, your own project, rather than taking down, you know, your company's servers by accident.
Eric Matthes 59:35
Yeah, this, this project, is an interesting boundary between the Django world and the non Django world, and so we're speaking about people like Jeff and Peter from the Django world giving input about what tends to work well for Django. I've had some interactions where people from specific platforms have popped in and said, Hey, this is what does work better on our platform. So they'll know something about. How their platforms read and ingest the Docker file in the safe for our platform, you should include this piece or modify that. And so this project sitting at the boundary layer, like that, that plug in is really that boundary layer between the Django world and the platform world. It gives a place for people with expertise on both sides of this this world to share their their learnings.
Carlton Gibson 1:00:25
What just sounds? Yeah, no, that just sounds such a wonderful world to be in, like, you know, you know, as it matures and you know, the plugins grow, there'll be a kind of canonical place you can go and look, even if you don't use it, you can go and look and see some things that you might not know and otherwise,
Eric Matthes 1:00:44
yeah, it's, it was really nice for me to see that I with the VPS work, that we don't need a separate plugin for each of the hosts. It kind of, I was a little intimidated by thinking about how big the plugin ecosystem might grow, but it really shouldn't, clearly one for each proprietary platform provider, and there's no limit if somebody has this super customized workflow that they want to write a plug in for, there's nothing to stop them, but we should be able to to basically formulate a good like Gun of corn caddy approach for VPS, a good Docker one, and that's separate from the gun of corn caddy. But like the the VPS that I'm using, I use SQLite on the server. I don't I don't want an explosion of CLI args, but one arg I'm gonna add is dash sdb. And so you can choose SQLite or Postgres, because that's just a switch in the configuration. I don't want to put like, DSD, VPS, and there's a flag for whether you want to use Docker or go to court, or, I shouldn't say that, because you use that within Docker. But
Will Vincent 1:01:56
yeah, I see, I see your point. Yeah, yeah. Carlton, you have a puzzle. No, I
Carlton Gibson 1:02:03
was just saying, I was just thinking about you saying you add a CLI flag for specifying your DV, rather than, like, putting these kind of things in a config bar. Or you might have, you know, or a 2e that does a quiz and says, because, like, right? Command Line flags are a bit of a paint type, right? I don't know anyway, this is just a sort, it was literally just a dazing off into creative world.
Eric Matthes 1:02:32
Yeah, that's interesting. I think I lean towards CLI args because it's, it's a constraint, I know. I don't want too many whereas starting to find a config file, the whole goal originally was to you run a couple commands and your project is deployed. So yeah.
Carlton Gibson 1:02:54
And I guess if people need something more complex, and that's when do your own, do your own plugin, comes in. Because, right? You know, you can imagine things like s3 argue, you know, values and a secret store and a DB that you need to connect to, and a Redis cluster that you you want for caching and simple deploy the default plugins don't need to provide that
Eric Matthes 1:03:19
Right, right? And so, you know, one of the things I wanted to kind of close out with is, where do I? Where am I going from here? You know what's simple. So if we're talking, if we're talking deployment of a simple project to fly or APU, maybe your first VPS, it's fairly simple. When you talk about AWS and the services you're naming clearly, not so simple anymore, but I think the name still works, because the name is there's a simple story for deployment in the Django world. And so if somebody who knows AWS well writes that plugin, then yeah, there's a simple deployment story for deploying to AWS, maintaining it might not be simple, but the initial deployment and so again, it's a it's a good story for that, because you think about all the work people go to like, learn how to get something functioning off of AWS. Yeah, no, it's not easier to have something that works that you poke at. Yes.
Will Vincent 1:04:21
All right, we're at that point in the show. I need to ask you again, you have the wand. It can't be around deployment, but we're still doing, we're still doing Django. There must be something, something else that you'd like to wave away.
Eric Matthes 1:04:36
You know, I gosh, I have a post every year, every January, I kind of go through that question of, Do I still want to be using Python? Am I using it for the right reasons, or am I using it because I already know it and I stay with Python because it lets me solve the problems I care to efficiently and effectively? And so that's the same thing that keeps me in Django. My work going forward is going to be to continue to clean up this core plugin boundary for simple deploy, clean up the testing story. If it becomes an established project, we'll have a separate conversation in a year or two about the entire testing story, because it's it's pretty interesting. But I also want to go back to my own Django projects. I have a project focusing on math education, some projects about music and whatnot. So Django worked for me and I don't run into any of the rough edges, and there's enough shared knowledge out there that when I run into something that doesn't work, I could figure it out. People answered my questions. I've occasionally run into some libraries. I think it was like, there's a modified, prepared traverse tree, something like that, Django, mptt, and I was using it for, yeah. So that math project, it tags math problems, so that the spirit of that problem is, your kid hates math. Your kids loves Legos. Your kids learning algebra. Can I find some math problems that are about Legos that use algebra? You click those tags and and have a bunch of math problems that your kids would say, like, Oh, I didn't know math could be like this. So I used that library, and it didn't do one thing quite right, but I was able to fork it and modify it and communicate that with the founder. So I think the things I'm most excited about in Django is probably Django, not space, because seeing this steady stream of newer perspectives who already have their hands in the Django code base feels really good.
Carlton Gibson 1:06:49
Yeah, no, absolutely. It's, you know, it's a massive it's a wonderful innovation, I think, is the way,
Will Vincent 1:06:58
right? Well, we could keep keep talking for quite a while, but we will have show notes for all these things. Everyone. Check out Django simple deploy, Eric, thank you for taking the time as always. Yes, yeah. Wonderful me. All right, we'll see everyone next time Django chat.com and bye, bye, bye.
This episode was brought to you by Buttondown The easiest way to start send and grow your email newsletter.