Transcript: Sticking with Django - Florian Apolloner

More on their services later in the show.

I'm Carlton Gibson, joined as ever by Will Vinson.

Hello, Will.

Today we've got got with us Florian Apodnos, longtime Django contributor, former security team member, former steering council member, he's everything, and yet somehow still so young.

Florian, thank you for coming on the show.

It's a pleasure to be here.

Go on, Will, go on.

Like what what do you know that he doesn't?

So um

When did you first start with Django?

How did that happen?

It was quite quite early.

I think um the famous magic removal branch um had mostly just happened.

So give me it a long time ago.

I I can't remember the old code anymore.

Um I I know I saw a bit of it, but I I know Django like it is nowadays, which speaks a bit to its backwards compatibility, right?

What was it or 2007?

What was it that led you to Django?

Lawrence, Kansas, so

And I was always impressed.

Um I liked playing Age of Empires 1 at the company um computers and so you

And uh at some point I wanted to do what my father did, namely programming.

And so we started to look for a project that we could do because um I'm really a bad learner if I learn something just for the sake of it.

I need I need a reason to do something, right?

And uh our idea was to write a cookbook software where you where we could put in our dishes and recipes, and we started doing this with I think Turbo Gears.

I'm not sure if um ever used it.

And um used um at the time Xul, uh, this was the um XML user interface uh Mozilla used quite a long time for Firefox, where you could create um native-looking user interfaces in the browser, which was kind of nice.

I'm kind of sad that they dropped it, and so we started um working on this application, and at some point it I don't know, we became bored or so and looked around what there are other options, and then we found Django, and from that point on it was Django.

Is that the

Um I think we actually rewrote it every year, and then at some point um we got bored rewriting.

And this was the time, I think around 2006 or so, um, when I met Armin Ronacher.

Uh he lived well, near me, a hundred kilometers or something, and we uh met at the bar camp and he was working on Ubuntu users, which is the um German Ubuntu platform, and we had, or they at the point uh at the point in time had a software containing of um PHPPB, the burning board software, um Moin Moin Wiki, the which was Python-based already, and something self-writ

ten, a news portal in um Django.

And they were already rewriting it completely to Django, and at this point I joined, and I think it's one of the largest and oldest Django deployments still running in Germany.

So if people are looking for a long-lived open source uh Django application to study from, they could perhaps use that.

So we we never got around it.

Um I also was against releasing it to be honest, because uh we we didn't know what we were doing, right?

Um and the code evolved.

We we had our own user model, we had everything, and it took us a while till we could switch to the user model or the um abstract user model Django provided.

We had our own, I don't know, caching before Django got those caching options.

So release after release, we um worked hard to port over to modern Django and yeah, modernize the whole stack.

So I'm curious if you could uh what do you make of the current status of the Django user model?

And do you have any thoughts on because there's a number of proposed changes to it?

How do you feel about all that?

Um I

I'm a I'm a bit torn.

I I see the recommendations is like always start with a custom user model, but I always

Carlton got that taken taken out of the book.

Well, no, no, no, no, no.

We've been sort of like silent, not intentionally not talking about that for like half a year now, Carlton, but the change has been out there.

No, come on, for him.

Finish it quick.

I mean, what if if you think as we're going forward, what's the best story?

Um, what I would like to see more in terms of um business applications is actually um support for um open ID Connect, at which point the user model becomes a little bit more well irrelevant.

What I see, what I use it currently still for is that like um I'm syncing the groups that or rather I get roles from open um ID Connect and then automatically um create groups in Django for that and assign permissions and so on to that.

So all I need basically is um some user model.

Um I I don't think I even fill the first name and last name, I just um

Yeah.

It's it's one extra query compared to, well, I don't know, the the work maintaining the custom user model or so, it's simply not worth it for my use cases.

But um, I'm mostly doing internal applications, and you can tell users there that well, it is like it is, and we are not going to change anything.

I've been thinking about that recently because we could take on some sort of mega project and try and merge everything into core, or we could at least for a first part try and like document the ecosystem options out there.

And what what's your sort of take?

What do you how do you think we can move forward in this space?

Because you you know it's difficult for us to bring everything into core because we just don't have the capacity to maintain things.

But it's like you have login with Google, you have login with Microsoft, and um, depending on the directory provider, you don't get back a username, but like a domain name, which a display name, which looks ugly, and keyclock gives you the full name and whatnot.

So I'm I'm not sure.

Um I think we should look out a little bit, um, just because we are using it at work, um, is Java and the Spring ecosystem, and they have relatively good support from what I gather, what the developers are telling me, that they can easily like um add um open ID connect to an application, and it all basically works.

And I haven't looked at that because I'm not a developer anymore, but um, I guess we should take more inspirations from other frameworks, be that Spring or Rails, uh Ruby on Rails Omni Out, which GitLab uses, and maybe see what they use and then draw the conclusions from there.

At least for some things.

You always will need extra templates, probably, because like um you want to put login with Google at the first position or something like that.

And I would question whether it makes sense to have this all in code or just ask the user to reorder things, reshuffle things in a template.

Um it's also like do you support just one authentication provider, which is typical for an internal um enterprise application, or do you go software as a service and need to support based on like the email domain of your username, different IDPs?

It's a different health story.

Yeah.

He's doing a lot of really great work kind of pushing all this forward without the community needing to get involved.

So that's that that's a positive thing.

Like he's already he got a grant and he's already done a bunch, but I think I I just use Django All Auth honestly as and it has most of the things I need at this point.

Um if I remember correctly, it reads the role from the um user info endpoint, and our IDB um per default um gives it in the access token or in the ID token, I think in the ID token.

So and it's not not really um well documented wherefrom it gets the roles or extra attributes, which makes it a bit hard, but uh generally I think it's the best option currently.

But you have to dig into the code, especially if you want to do more than just login, because what's very important for us is that we we get some kind of roles that we then can map to permissions on our side.

Can you expand upon that?

Um the funny part of the story is that um when I started at the current company, um, I actually got uh or was forbidden to do any code.

Um the idea behind was uh that we actually need a system administrator um way more than another developer.

And to ensure that the priorities are set straight, I was not allowed to code, which was mostly in chest, but um still holds kind of true.

Um, but I mean that's like I think seven or eight years in.

Clearly it's engaging enough to keep you occupied.

I I'm thinking about silos in the context of I've been very much head down in the web space and I'm doing a DjangoCon talk on Django and data science because you know data science is a thing that I know very little about.

Um so I'm curious, someone who knows both Django and then you know, let's just pick on system administration, what yeah, what what do you see as the similarities and differences between the two?

I mean it's all programming, but it's a totally different world.

I actually like to see more people getting involved into system administration and coding at the same time, because um there is there are so many things like um you you have to think about your software from a different perspective, right?

If I'm getting handed down software from the developers and I'm putting it into production, I need some um some kind of conventions, be that like this we have config files or we pass it in via environment variables, and um you need useful log lines, especially if you don't um speak the language the program is written in, which can happen as well, or usually is the case if you're a normal system administrator

, and I think software development can or in both directions, um, we can learn from each other because there are like this structured thing for a system administrator where you say you want your log lines all in the same format, um, independent of like whether I have 10 applications or 20.

This makes also sense for a developer because they are faster when all their programs output the same log format.

It's um easier to um recognize patterns if you don't have to focus on every new log line and um guess the format and so on.

Was that if you get developers closer to ops, they can think with an ops mindset and vice versa.

So I'm it's like nowadays it's sometimes feels like you don't know enough from either world.

Um and I think it's better to have like a developer who's interested in operations and a system administration who is uh administrator who is interested in development, um, but you can accept that you don't wear both hats.

I mean in smaller companies it's often happening, right?

But um this distinction still makes sense, but you you have to look um over the border and see what the rest of the company is doing.

You you don't want those silos, right?

No, I'm not gonna deploy it, throw it back over the wall several times.

Yeah, that's obviously not healthy.

Um you you have to think about how to handle secrets, and you you need to support from the developers.

They they need to adjust in the worst case the application, um, depending on whether you are reading the secret from, I don't know, Vault or using a HSM for um hashing or signing stuff.

Um is completely changes the um completely changes how you work because quite often you can't use a few libraries um because like they make the assumption assumption that you always have access to the private key, which if the private key is not on your system is not going to work.

Sorry, there's talk in the Django world about um trying to do something to smooth the the road from so the start project template is very the beginner friendly, it's very you know get up and running, but it's not there's quite a number of steps to get to production, get to deployment.

It's like a big challenge that people have.

And one of the questions is about secret handling and whether we can build in better handling of environment variables or you know.

Have you got any thoughts about you know if you if we could do something in that space?

What would you like to see?

Um the well, where where to even start?

So um I'm using uh I think Django Goodconf, which um gives me all this environment handling, which works um nicely.

But as soon as you start to integrate um secret management systems, especially with rotating secrets, um it becomes really really hard.

Like if you think about our database backends, you can't really I mean you can if you overwrite the database backend, but like you can't change the password every five minutes, and same goes for service discovery, like um a new connections should always re-resolve via console or something.

Um, this is really hard.

The Django settings module works best with um static credentials, and I'm I'm not a fan of environment variables.

I try to get rid of them um as far as possible because

But if you're using um Django and having a Python project, it can happen that you, I don't know, call out to some sub process.

Uh and this sub process automatically inherits all the environment variables by default, usually.

I mean, there there might nowadays be um some options, and Python nowadays also closes, for instance, open file descriptors by default.

But in the earlier days, uh this all got inherited to the subprocess.

And especially if you're using the subprocess for things like uh rendering a PDF file or something, and you got an exploit there, you have access to all your secrets.

And I think every code execution remote code execution that I know tries to look for secret secrets via environment variables because that's since Heroku, um I think Heroku was it with the 12-factor stuff, um, popularized it really, really hard.

And now you know if you are inside a process, you have environment variables.

And if you put all those things into files, it's way more you have to figure out where where the file is.

I mean, that's it's not exactly hard, but if you take more off-the-shelf stuff, um and depending on the system, it the environment variables are leaking around everywhere.

I mean, it's as the same user, you can always um look them up in the proc file system on Linux, which which is kind of okay.

I mean that that's how it's designed and it works like that, right?

But um, yeah, uh a file is easier, I think.

Yeah.

Because I think for when people starting out and they just hard code the credentials in the settings file, that's clear a step to move to environment variables is clear a step up.

But then there's a step beyond environment variables for the reasons you've talked about, because they're not they're not the securest thing in the world.

And I think any solution that we have in Django needs to account for the evolution along that pathway, right?

It needs to have backends for you know proper vault systems as well as environment handling.

The main question that you usually have to answer is um how does this backend work, right?

Um, do you uh read up all environment variables at startup, or do you access the environment once the variable is accessed?

Because this at some point begs the question do you have a schema and can read all the needed data in advance?

Or if you need to go to an outside system, does that mean an HTTP call for every variable when it's first read?

Or can you like in in bulk read read the whole configuration?

And this is where it gets interesting and hard, I think.

And you usually you can mix and match them.

Um one thing I ran recently in two was um I'm running, I or I wanted to run systemd inside a Docker container and use that to start my application because I'm trying to ship my applications a single container.

Um and this really easily breaks down if you use environment variables because systemd won't start your service with the environment variables that you passed into the container by default.

And so if your application just reads a config file, it's readable from everywhere for your application, and you don't have to think about whether it started via systemd and are the environment variables passed down or not.

RAM it in there.

Oh we we are currently playing with it, it um actually solves a bit of problems for us because you can um store the credential um as the root user on the system and then provide it to the service and then it has access.

And um in combination with containers, it you you get very interesting and great deployment patterns.

For instance, we are also using um socket uh socket activation, like in a D style.

And so we have our containers without network access, but they provide an HTTP API to the outside world, which is perfect because you can now um execute some code that might call out to the outside world, like um any document, literally, like um printing an HTML page or something, which could include an image, and this is all blocked by default because the container has no network.

And I think systemd provides some nice deployment units in that sense.

So I I was gonna ask, like, so you you're right into the world, you're right into deployments, you're using quite advanced um containerized whatnots and Kubernetes, I guess, and what I don't know, not Kubernetes, right?

No, so I was gonna ask, what what's the what's your kind of what are your favorite things from that landscape from of all the the tools that come by?

What are you the ones that you think, yeah, no, that's that really makes the difference?

Um we are slowly evaluating Kubernetes.

Um I'm I'm impressed by what I'm seeing there, uh, but I'm also kind of afraid.

Like uh we we need to understand um our systems, and we just so just for context, um the company I'm working at um is a trust center, which is um under the eIDAS regulations where we concern ourselves with um digital signatures and whatnot, and we basically have an uptime of uh 100%, also 99.999 something or so uh for the last five years

And this includes basically maintenance and everything.

And we we are really really afraid of systems that we don't understand.

And I I I like the fact that you can put a database onto Kubernetes and the operator, so they this they have this operator pattern which will upgrade and make backups and everything.

But what happens when the operator goes wrong?

Um, sure, it's better tested than your usual setup, but when it goes wrong, you you have to fix it anyways.

They happen.

Yeah.

So we we have anzible, we can deploy a new virtual machine in minutes or actually seconds what it takes to clone it basically.

Um after that, um, Anzibull runs over it, and usually that's it.

So we get certificates issued everything automatically, and um, then we can use the machine.

And it's not like um we don't need to scale that much.

So we have a rather static setup, and it's questionable how much Kubernetes makes sense there, right?

I mean for some things, certainly in the future, but um I still think that Docker Compose per se is a nice um deployment pattern because it allows you to um put things together nicely with with all its ups and downs, like the network routing and everything, but no matter what you use, right?

You you have to know the stack.

You you have to own it if you want to be successful.

So that means providing patches to DocCop Botman as well and digging in really deep.

From custom software development to consulting, team augmentation, or opening an office in Bulgaria, they're ready to take your project to the next level.

I want to ask you if there's So you're on the security team for Django, and Django is well known for having one of the best security stories out there, but that's very much behind the veil because people submit them privately and and they're handled.

I'm curious, um I'm sure there were some wild stories of especially early days, security issues.

I don't think that

Um mostly it's like denial of service, um, quite often via regular expressions or something.

And I guess the worst thing that we had, um, which was only in the main branch at the time, um, when we moved the login view to uh class-based views, or was it the password reset view?

Um, you were able to reset a password for any user without the um the password reset link basically.

There it was really a subtle change, but um that that was horrifying.

I I wouldn't have wanted that on a live site, right?

Well it but I mean I mean Carlton, you're are you still you're still on it, Carlton?

Hanging hanging on in there for now.

So yeah.

Yeah, and they remember they published they published a blog post about how they'd fixed it in Rails.

And Simon Charrett um was reading his you know with his coffee and his RSS reader that pinged them a security list, it's like, hey folks, I think we need to do something about this, and we all have a quick look.

We're all like, oh yes, and then so a hotfix went out, I think, the very next day.

And normally Django has the um seven-day pre pre-announcement um and to tell people that the security fix is coming.

But on that one, it was like, look, because because this has been made public and it's it's quite it was quite a serious vulnerability, as Florence says, most of them are kind of denial of service ones, which probably you know they're they're they're worth fixing, but they're questionable of whether an individual installation is going to get hit.

This is kind of like a a much more serious one, and it was like, no, we've got to drop the seven-day advance and just put it out as fast as we can.

That's the one that comes to mind as the sort of most pricing from my time running.

Um, if Flask has an issue in its HTTP handling, I bet Django has it as well, and also in the other direction.

I mean, it happened once or twice, I think.

And um, same goes for PHP and Ruby.

And this is something with all this um yeah uh security posture going around nowadays with um we need software inventories and whatnot.

Um, what we first need is to talk with each other and find a common channel where we can like um easily um exchange security issue classes basically actually um where they say like we got this kind of problem.

Um, can you look if you also have it?

Because chances are that most systems have it, and sometimes you see it in the um published uh issues that day after day a new framework joins the release process and says, Oh, we have the same issue, we have the same issue.

And this this is something which would be great to work on, but it's it's really hard to get like multi-language programs started, right?

And so it it you know, it's like okay, we need to stay on top of that as well as reaching out as well.

And is there a common space?

No, there isn't.

I mean, I wonder if we can get something going with Python and you know, with Seth doing such a good job there if he could nerd herd us into the same room.

Lauren, so you said you were still working on your internal application at um with Django.

Yeah, okay.

So after all this time, what keeps you fresh?

What keeps you staying with Django?

Is it just that you know it or are the bits that you think no, uh that's why I'm well

Um I I don't have the time to um play around and learn a new framework just to uh write an application for internal use.

And the other thing is uh what what I still like about Django is that um even though it's sometimes horrible to work with, uh you get everything out of one hand, right?

Um you don't have to explain to someone using Django how forms and models interact.

And I I don't need so many extensions uh or um dependencies in that sense.

The the current project has like I think five or so, um and this is uh massive for me, especially this is by no means uh anything against Flasco, so but um when I need login, I know I can count on Django to some extent, right?

There's no I'm open ID connect, like we said, but I've got that covered, I've got form validation covered, I've got models, I don't need to think about how to integrate um SQL Alchemy, which I laugh and think is way, way, way superior than the Django ORM in some sciences.

And the same goes true for Flask itself, but it's like this thing um you where you have everything out of one hand and you have one documentation to look at.

You have one channel for support uh where you don't get told to this is not a problem with um the form handling, but is with the models to this this other channel because this is all a different company or something like that.

So that that one hand, that battery's included, I guess you could if you think about the scope of Django as it is now, and thinking about this from you know, we constantly add things, but do we ever take anything out?

Is it are there bits that you think we could retire from core or take out of core or separate?

And and contrary to that as well, other bits that you think no, actually, I'd like to bring that in and that's missing from my

But it's it's hard to throw stuff out.

I I understand that, but all in all, um I I think the the scope should should stay roughly.

Um I I also wouldn't want to um add too much support, for instance, for HTMX.

I I know plenty of people are using it, but um it's still like it's it feels like new, it's great.

Um some people are using something else, and maybe maybe in three years um we are back to some uh somewhere else, but um this is especially an area where we can um experiment outside, and uh you know when we added for um I think it was template partials where you needed something to make it work.

Um, this has been the story for Django all along, right?

Um, what's the minimal thing we can do to uh enable you to implement your ideas?

And in this case it's two lines, and you can build Django template partials which offers much, much more flexibility.

But what you needed in core was one line.

I understand that this doesn't work for stuff like authentication, or not always, where say, like, yeah, I would feel better if I don't have like 10 libraries of glue code.

Um, I want one security solution and want that to work.

I see you have a repo on it.

Have you had a chance to play around with that at all?

Okay.

Yes.

Everyone is complaining every time that um packaging in Python doesn't work, which like I guess is or was true to some extent.

But for me, it's um how to put this?

It's like writing a web application without knowing HTTP, right?

Um you you can use Django without knowing HTTP, but you you have a much better understanding of it if you know that HTTP is supposed or yeah, is stateless and what this means, what when you should get uh when you should use get, when you should use post, and what the um implications of that are.

So for me, UV is mostly um useful in the sense that I've I'm getting a single binary that I can easily um include in my Docker files in my um intermediate build containers without having to install much and from that on let UV take over.

But similarly, I had the same thing with um Poetry and PDM.

Um I'm I think I'm switching my package manager for Python yearly.

So okay, okay.

And I think when I ask around, most people who've who've tried it are like, yeah, this is certainly for the foreseeable future, this is the way to do it.

And while I understand that um stuff doesn't move fast in open source, it's like when you're when you can't build your project anymore because um some new package got released somewhere which breaks the dependency resolving of your package manager, and it's it's not like um resolving packages is an easy task, right?

Uh so it's it's not something I can fix even if I want it.

And it it really helps to get a quick turnaround there, and even if it's um like with some stop hatches to explicitly tell the package manager, use just this package.

I don't care whether it works on Windows or not, I don't care if it works on a Mac, I just want it to work in this specific Docker container, and this is my deployment unit.

It's great that it doesn't resolve for, I don't know, CUDA and whatever GPU stuff you have nowadays, but that's not what I need.

Because I think a lot it's obviously written in Rust, but I don't I think think most of the enhancements are just um because it's cleverer about how it searches for packages and it's it's more aggressive about caching and things like that.

I wonder if you know anything about whether those those speed gains can be brought into say pip or like you know the community tools.

Um so it's certainly doable, but I'm I'm not sure if the resolver itself um I mean the resolver certainly uh plays part in it, but I'm just guessing I I haven't profiled it.

But what I do know is that there is aggressive, really, really aggressive caching going on, um, to the extent like uh when your uh package is installed and it's installed in editable mode, and it then gets put into the cache with an explicit version, and which means your later log files will um then include this version instead of your project, so instead of your dev version.

I mean that got fixed, but there are um we are moving to caching bugs now in UV.

So whether that's a good sign or a bad sign, I don't know, but it it certainly works and it works fast.

Uh this is probably just because I started working at JetBrains, which makes PyCharm IntelliJ.

I'm curious what what text editor ID do you like to use these days and why?

Um I I was using Vim for a long time before, but the um yeah, the the easy, let's put it that way, the easy integration of autocompletion and everything uh won me over.

I I do know that I can do everything with Wim and Emacs as well, but I I just don't care.

Um, especially if I'm using Vim on servers, I or usually Vim is one of the editors installed on some servers, not not those necessarily that we manage, but um I had my fair share uh working with other servers, and you you have a default configuration there, and once you use Wim on your local laptop and connect to a server and the configuration is different there, it's uh it

stops becoming viable.

This this is one of the reasons I don't want the editor that I use unconfigured with the default settings for system administration, also be my programming environment.

And Visual Studio Code was fast enough.

I'm I'm still an unhappy user, so to say, because um I'm I'm not going or I can't justify paying for I'm maybe I could, I don't know what the policies are or if it's possible to pay for it.

But um, with all these um Python plugins becoming more and more closed source and the digital write management stuff around it, um I'm I'm not too happy about it.

Um I understand parts of it, but uh I haven't found a better solution yet.

And also, I mean I know uh we we do use chat prints here and there, but um, and correct me if I'm wrong, um last time I looked at it, it was 10 years ago.

Um, but I think it's still like you have uh one program for um one language, and um in Visual Studio Code, I have some plugins and it works well enough, and I'm I'm switching between five languages a day, so I I wanted the consistency.

There's some truth in it.

Uh I think it's not totally true.

For example, if you use PyCharm for Python, it also pulls in um WebStorm, which has support for JavaScript, TypeScript, HTML, CSS.

So you know, if you want to job hop over to Java, you can't do that as easily.

Uh so there's I think JetBrains doesn't talk about that the bundling, uh partly because there's like the pro and the free version.

Um so it's it's mostly true.

Um I mean there's the it's interesting that there it's a little bit VS Code is a little bit like Flask in that it's micro and then you rely on the community for most of the plugins that you want to use.

Whereas uh JetBrains is a little more like Django, it's all in-house.

I mean, under the hood, it's this it's basically the IntelliJ Java engine.

So there's like a global engine that drives things, and then there's specific things for PHP or Python or what have you.

So it's a little more Django-y.

Um but yeah, yeah.

At the end of the day, that's a common thing people say.

And I think if you are bouncing between a lot of languages, like I certainly understand why you'd want just one IDE for that.

I'm mostly looking at code, but on a normal workday, it's probably Go, Rust, in the worst case, a little bit of C, and then usually some Java and whatever I have with Ansible, I so mostly uh YAML scripts or YAML files.

And it's I I need most I mostly need syntax highlighting, and that's about it.

That do you know about this project?

No, it's I I have it's from the the people who made the Atom editor for GitHub.

Uh Will Will Klopp, uh who's involved in the Django community, he's yeah, it's public.

He just started working there part-time.

That's interesting.

They're it's interesting that they're not going a thousand percent AI focus yet, the way everyone else is, right?

So obviously VS Code is, JetBrains is, uh cursor, you know, there's sort of these two extremes of like, you know, have AI, have full integration, the agents and stuff.

And then there's also I just want a text editor IDE with some syntax highlighting that isn't slow, right?

And I mean, um looking at other things is um part of my day job, right?

And so if I am to change my personal editor or something, the the pain it inflicts on me needs to be really, really high.

I just don't have the capacity to change my system and everything every other day because um that's already my day job, right?

And I I want some consistency in in some things that I use.

Um I'm I'm not involved in those discussions.

Um I actually don't know, aside from um coffee table discussions, if there are any.

Um, but I I honestly don't think it would be a problem because uh we would still have code review and everything, and uh it would still be your fault.

Uh not not that we assign blame or anything, but you you have to take ownership of the code you want to submit.

And um I I I think um like Simon is uh Simon Wilson is blogging quite a bit about it.

Um it is like with everything.

Um if you know something like Django well, um an AI can help you iterate faster.

And I'm I'm not sure if it may maybe it was Guido in his early days uh after joining Microsoft or something like that.

It might might have not been him, but I have this quote or rough quote in my head where he says, like, you don't need an IDE if you know where everything is, right?

And for me, this holds true to some extent because an IDE doesn't help you find stuff all the time.

You still need to know where to go looking.

And I see this nowadays with Visual Studio Code.

I'm I'm not doing that much Django anymore.

So I use the auto-completion and I like I need to import a response object or something like that.

And I get a completion with 30 response objects.

Um, 10 response objects are from subprojects like Django DRF or Django Ninja, which re-import and so you you still need to know which response object is the correct one for the task and whether this is just a forward import or if it's a subclass.

So, yes, use AI by all means.

I mean, I would be careful or ask legal whether I can send stuff outside our work perimeter, but in the end, it's a tool like everything.

I I wouldn't be too afraid of it.

Okay, fair enough.

So there's something around like these tools help you find stuff in a huge project, but then you just want something minimal if you you know know exactly what you're doing.

I would also say that that's part of so I'll just say one more thing.

Like, you know, if you see a drop down of 30 30 imports, um that's something that, for example, like PyCharm has a Django integration.

So I think in some cases at least we do a better job with that, but like how do we I'm only a month in, so how do we communicate that?

How do you say that you know marginally better?

Uh it's it's hard, right?

Because we we we pick a tool, we get used to it, and then um, especially as you're senior, you don't really want to switch around your tooling that much.

As soon as you're going to say it, you're going to start a flame war because people will find this one edge case where Vim or so performs better.

And I'm just not sure if it's worth it.

And what came all out uh for me is that um this language server protocol, so all those um generic integrations into the editors, which are not always um that generic, but those helped a lot, and um, this is really important for me when I look at a Go project or Rust project where I have literally no idea, and I'm able to find um sub-implementations or references to this piece of code, which is not

so fun in Python, which is um, I mean, chatbrains has good support there in Java, but with um all this dependency injection going on, like you can you can view all the implementations of an interface, but you still have no idea what you get auto-wired via configuration somewhere.

So it's really hard for me, even with the I I don't know what the chat brains um sub-IDE for Java is.

Um, but I have looked at that at one point and I I found everything I needed, but I just didn't know what was actually in use.

But that's not chatbrain's fault, right?

But if you take an interface, it can be anything.

So Rust, super, Go, great, Python, not so great, which leads us naturally into the question of typing in in Django.

It's come a long way over the last few years typing, I think, in Python.

What are your thoughts on that as we go into 2025?

Like, how do we push that forwards?

I I personally I'm now at the stage where I would like to see it.

Um I'm not sure how to start, right?

Um, because for instance, we we need to be able to type the low-level objects first and then kind of build up from that.

So I I don't think that an approach where we uh just annotate new code is going to be uh that helpful, especially we would want to have like um type checking in CI that verifies that we're using it correctly.

And if um 90% of the code base are not annotated, I honestly don't know how this is working.

So um, but that's just me not using typing that much, especially not in Django, because it's not there.

In my other projects, I do use it, and um it is really hard, I I have to admit.

So whenever you are trying to do something tricky, it it sometimes feels like I'm writing C again, right?

Um, in the sense that uh in in Python I I have this elegant idea, this is done in one line, and then the type checker says, Yeah, you can do that.

Yeah, okay, I know I can write it like I would write static code with no extra features.

Um, and then my types will work.

This is probably a bit unfair to both languages, but for me it is really hard to get started, especially um like when you say Unicode and text, you have like um be be lenient in what you what you accept, uh, but you have to be uh strict on output, like HTML rendering and everything.

And this kind of is the same thing here, like in typing.

Do you take a list?

Do you take an iterable?

How um how far do you go?

Um what what happens if you take an iterable and you want to be strict in your output?

Then you put a list or something there.

But does the iterable convert to list?

Probably not, because it can be anything.

It said no, it has to be they added a check where allowed hosts had to be a list.

And I'm like, but I've got a project from the old days that has an iterator there and it's just broken, and like why?

Um, I I really see the benefits, especially in in smaller projects.

Um, at one company where I work, um, we had like um communication with phone systems, like in a hotel uh guest check-in, check-out, and stuff like that.

And those are um phone systems from really old age, basically, where you have serial cable um updated to Ethernet uh via converter and so, and you basically get the raw serial stream over TCP or USB, depending on what you use.

And we were writing code against that, and nowadays um with Python, and it was really hard for me to write tests for such a thing because the the code was async and I tried to write it with this um Dans Io approach.

But in the end, for some projects I just can't justify writing the tests.

Or I mean that's probably not true, but it's it's really really hard, and typing there helps a lot.

It it eradicates a whole class of um mistakes, I think.

Be that typos, I mean the the IDEs are already good with typos per se, but everything else, like uh trying to add an integer to a list or something with the wrong operands.

Um, this is really really great, and it shouldn't mean that you don't have to test um anymore, but you you don't don't have to test that much, I would say, because previously you have you're taking an object basically, and you either have to document very carefully what the function actually um takes or you have to check inside and throw errors, and then you would want to test this.

And now you say, okay, but if I say this is a string or something, I rely on the type checker during development that it ensures that it's a string, and then I don't test what happens if I pass in an integer.

As soon as it compiles, often it just runs and it you know is bug free because you've satisfied the compiler, and the same applies with type checking, right?

To a certain extent.

Okay, so uh I've got one more sort of question I I want to ask you.

Is it as a you know a very long-standing community member?

You see where we're at with you know discussions and featured requests and you know the difficulties we've had pushing Django forward, I think, over the last few years.

It's been very stable, but you know, there's there's there's been a lot of desire to push Django forward.

How how do you think we can do that best?

What are your sort of you know, as you as you watch and as you partake in the conversations, how do you think we can move forward now?

Um, part of me not being this active with Django anymore is um probably kind of well I I wouldn't call it burnout but um it's this this inertia that exists where you you just can't get anything off the ground because no matter what you suggest the default setting is no we we are not going to do that.

And this is the reason also on the other hand why I like programming in Django because I can rely on it to work like this in one year which makes it really really hard.

One idea that just came to mind literally now so no no idea if it's uh viable is to ask um other communities like Rails or Spring um to talk about exactly this on Django conferences that they provide their experience um how they managed to move beyond such a point or maybe they didn't have this point uh this problem at all and

this would give us an outside perspective um I think we're we're doing better recently than we did a year or two years ago um especially with the new steering council as well because I think the uh we we need to make choices now and I'm I'm happy if if someone makes those choices and I I whether they align with what

I want is not necessarily um required um it's just there is a choice and we know this is the path forward.

For instance the async support in Django is something that that lingers around with no no good path forward I think because do we want to add uh duplicate code for every um method I don't think so and now we have this this code generation idea and we we will see how it turns out personally I'm I'm not using async Django that much and um I I'm not sure maybe

for some parts one can use it but I I won't see Django as a general um async framework especially with um this handling um or how the async code in um python generally looks i I mean it's not so bad nowadays but I have bad memories um of the callback health in JavaScript and to some extent in twisted which which really makes it hard to follow the code

and this is probably because I stayed away from it and also I I don't need it.

I for a general purpose homepage there is no need to serve every view asynchronous if you especially with Python 3.13 I mean it started there it will get better and free threading we finally have the possibility to catch up with our web servers and spawn like a hundred threads and this is what we can handle instead of a few processes.

I mean we for example we had David Hannemeyer Hansen on this podcast early on I my hypothesis would be that if you look at so Java Spring VMware largely runs that Rails Ruby on Rails you know that's David Hannemeyer Hansen he largely runs that still if you look at Laravel you know they raised $72 million and one person kind of runs it you know that's that's kind of the difference is that all these other ones were competing against you know fast API it

's Sebastian in charge.

They they do have a little bit more of the BDFL not not not they do sort of they definitely do so they can move faster right so I think the the question is over the long term what happens when those companies or people want to step down but you know that's I I strongly suspect that's why they can move faster because there's someone with a profit motive working full time whereas there's no one in the Django community doing that.

If they end up in the same situation as Django then I don't know but there there is enough is incentive and money behind it I guess.

It would still be a community right like so there's there's it's more the question of VMware or some for-profit thing that pushes it as opposed to 100% community.

I mean we always say we do have roughly enough money I mean more money would be good certainly but we don't really have the best plans to spend it yet.

I what I could imagine for instance is like if Instagram employed relatively early on um all of the Django core members and took it over that we might be in a similar situation like spring is because then you would have um a clear leadership in that sense I don't think that money provides this um clear goal of where to head next unless it's um coming with the tag like okay um this money is

for improving the OIM to this situation or something like that.

that stuff but find a way where we can just modulize slightly so that there can be three or four conversations going on which don't all have to go through the same bottleneck and I don't know quite how we get there but I kind of feel like we need to do something in that direction.

well with the models and um I I'm not sure if it gets better if we have more um boundaries in between um as little small slight they are but

should include or should not include and I think it depends a little bit on what you're doing right um we we already have start project templates um there is cookie cutter and um and copia out there which which I really like because it allows you to um release new versions of your template and then update existing projects uh you and you obviously sometimes get conflicts then but this provides some um nice way to um

actually update your projects without manually reapplying all your changes and what I'm doing is basically I'm I'm shipping applications right um I'm not um in an area where you say okay this is the application add it to your settings file and I'm I'm shipping complete application like um netbox or maybe venueless um ships and what I found useful is that you could just um use start project and then

immediately add um this generated project as installed application into your setting uh into your settings file um this solely means I I think at the current point it means you still have to um create an empty models.py file.

But aside from that, you're basically pain-free.

And then you can add further applications um as uh on on a subdirectory, sub package basis, because it's way easier for me to have like my current project, for instance, is named Oversight.

It's way easier to have an oversight.core application, an oversight.user, an oversight.something application than to think about valid package names for every application.

And it's it's meant to be used together, right?

And we we have this namespacing and we can use this.

And I don't I don't see any reason anymore for this project.

The project for me, so in in Django speak, is basically a settings file, or not even that, the the environment module uh Django settings, uh the environment variable Django settings module basically defines what your project is, and you can bootstrap everything from that.

So that's what I'm using.

The start project folder is the app itself.

And I think I think that's a big step forward because the you know, Will often talks about this with his books, but like you've got the start that first run experience where you go start project, now start app, now add it to installed apps.

Now which folder am I meant to be in?

Which file am I meant to be in?

It's just too much going on, right?

I'm I mean we would change the start project template probably to um account for that, so not just um add the application to uh the project to installed applications, but also like provide a dummy models.py and test spot.py which we don't use.

And maybe I don't know, I'm I'm sometimes moving the the whisky module into a sub package then because uh it's it's a little bit ugly on the top level, right?

But that's whatever you prefer.

But if you had it'd be nice if there was an official, you know, bootstrapped blog or crud with auth, or right, there's only two or three kind of things people want.

And if there was you know, start project gave you that, that would certainly up the learning curve.

And then of course the big one would be have production, right?

Where you default to production and you'd probably need to use environment variables, um, but have a have a way to do that, you know.

If I you know if if I could go work on Django for like a year, I would add those happily and just put them in because I think that would help newcomers for sure.

Do you want this JavaScript integration?

So basically um provide a kitchen sink uh Django template.

I I stopped doing that because when I'm using Django, I I use this one CSS framework, I use this one JavaScript library, and um I think in in all those generics uh there's lots to be lost because with all this flexibility there comes uh much more complexity.

And so we probably need like um 10 or 15 start project default templates.

But there are yeah, I think there are also um some Django um software as a service templates where you click together, um like I want to include authentication, I want to include um vault for secrets management and everything, and they are selling.

I I don't know how how well or something, but certainly an area to look at.

Um I mean, I'm not exactly sure about the business model, um, because

Then there's a dozen other ones I could name that do similar iterations.

Um my sense is that it seems people want the SaaS integration more than they want the rest of it.

Um, but like once you download the code, um probably licensing is stopping you from using it for another project, but um you get the ideas, right?

How such a thing is built after you paid for the first one.

So I I don't necessarily see it scaling that well inside one company that you can sell it um many times, but I'm happy to be proven wrong.

And if it works for him, it's perfect because that's certainly something we miss.

I think it's slightly it's people, it's an education thing.

People use, I mean, this has been done in other frameworks where people use a SaaS starter thing in Rails to get going and then fill in the details.

Um, I think it works a lot like that, actually, for people.

But yeah, I don't know.

I don't know exactly.

There's there is a depth that we're hopefully going to push forward in the 6.0 or 1 timescale to um update the start project template, make it a bit simpler in the way along the lines you've talked about there, Florian, and then also as part of that, try to promote using templates a little bit more to make it more obvious to people that that you know there are these templates out there, and you can create your own one, and you know, then maybe we can have two or three or four example apps, simple example apps that are like, oh yeah, look, there's a there's a blog

, there's a there's a Wagtail example, there's a who knows what.

And that's that's what copier gave me, and it's like reinventing the wheel.

Why why improve Django in this direction if you can use Cookie Cutter or Copia?

I don't know, maybe use something else.

Yeah, okay.

Yes, yes, let's do that.

So, Florian, thank you for coming on.

We've when we first started this podcast, you were one of the names we wanted to have on, and six years later, here you are.

Um, so again, thank you for making the time.

We'll have links to everything in the show notes, chat uh DjangoChat.com, and we'll see everyone next time.

Bye bye.

Bye bye.

Learn more about their services in the link in the description.