Transcript: Sticking with Django - Florian Apolloner

This episode is sponsored by Hacksoft, your Django development partner beyond code.

More on their services later in the show.

Hi, welcome to Django Chat, a podcast on the Django web framework. I'm Carlton Gibson,

joined as ever by Will Vinson. Hello, Will.

Hello, Carlton.

Hello, Will. Today we've got with us Florian Apollon, who's a long-time Django contributor,

former security team member, former steering council member, everything,

and yet somehow still so young. Florian, thank you for coming on the show.

Hello, thank you for having me. It's a pleasure to be here.

Yeah, well, no, I'm really excited to have you. Go on, Will, go on.

I was just going to ask, so you've kind of already lived the life that Carlton's just stepped into now.

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

I don't think I know anything he doesn't, but I probably had the pleasure of starting earlier, right?

Well, maybe let's start with that, because you are, for those who can't see you, you are still quite young, especially given how long you've been involved with Django.

When did you first start with Django? How did that happen?

So I think it was around 2006 or 2007.

It was quite, quite early.

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

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

right yeah yeah and um so how did how did a young person find it in 2006 what was it or 2007 what

was it that led you to django so um my father let me let me just rephrase that because you're not

based in lawrence kansas okay so um my father is based is working in it um as a programmer and it's

it is for medical clinics and stuff like that so not uh web frameworks but um internal clinic

systems and i was always impressed um i liked playing age of empires one at the company um

computers and so you had a big screen at no small screens there were no big screens at the time

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 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 have i used it and um used um at the time xul this was the

xml user interface mozilla used quite a long time for firefox where you could create

native looking user interfaces in the browser which was kind of nice i'm kind of sad that

dropped it and so we started working on this application and at some point 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. So if in doubt rewrite it from scratch?

Absolutely I think TurboGears wasn't even maybe not even the first implementation so

there were like three implementations I think we actually rewrote it every year and then at some

point we got bored rewriting and this was the time I think around 2006 or so when I met Armin

Ronacher. He lived, well, near me, a hundred kilometers or something. And we met at the

bar camp and he was working on Ubuntu users, which is the German Ubuntu platform. And we

had, or they at the point in time, had a software containing of PHP BB, the burning

board software um moin moin wiki which was python based already and something self-written a news

portal in 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

and that's probably open source as well so people are looking for a long-lived open source

django application to to study from they could perhaps use that yeah but um this is actually

not open source 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

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 worked hard to port over to modern Django and

yeah modernize the whole stack okay well you said user model which is was like my thing for

last year 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 don't know 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 not need not anymore carlton got that taken taken

out of the docks no no no no all it was a very small change i made it's like highly recommend

got rid of the really scary warnings that the world was going to end if you didn't i'm sorry

that i mentioned that 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 finish it quick

what do you think i mean if you think as we're going forward what's the best story

i i think the story is kind of okay 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

i'm syncing the groups that or rather i get roles from open id connect and then automatically

create groups in django for that and assign permissions and so on to that so all i need

basically is um some some user model um i i don't think i even feel the first name and last name i

just um it's just a foreign key yeah and for this player you get something from um open id connect

anyways and you can put it into the session in the worst case or have an extra model where you

store the extra data it's it's one extra query compared to well i don't know 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 okay so i was thinking about what you talk about open id connect there it's just

sort of one option in the auth world and i think there's lots of people that have come on the

podcast and lots of conversations we've had on the forum and place about how we need to sort of bump

up dango's all story is solid and it's good but things like 2fa things like you know third-party

auth providers and whatnot 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 how do you think we can move forward um in this space because you know

it's difficult for us to bring everything into core because we just don't have the capacity to

maintain things yeah so i guess this is one of the main problems because like days open id connect

but it's it's not it's standardized right but it's like you have login with google you have

login with microsoft and depending on the directory provider you don't get back a username but like

a domain name which is display name which looks ugly and keyclock gives you the full name and

whatnot so i'm not sure um i think we should look out a little bit um just because we're 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

bring more rails ruby on rails omni out which gitlab uses and maybe see what they use and

then draw the conclusions from there try and rob some ideas from places yeah because it's it's not

like it's not i mean it's a solved problem right 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 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 right and too complex for django to have one

simple answer for everybody right yeah well i mean one good thing is that raymond penner is

with django all off 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 off

honestly as and it has most of the things i need at this point i i do as well but um it required

quite a bit of tinkering around 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

I think in the ID token so and it's not not really um well documented where from it gets the roles

or extra attributes which makes it a bit hard but 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. You mentioned you're not really a developer anymore. Can you expand upon that?

Yeah. So I'm mostly doing system administration nowadays.

The funny part of the story is that when I started at the current company,

I actually was forbidden to do any code. The idea behind was 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 jest but um still holds kind of true so

you'd sneak back late one night just to get a couple of lines in right

um no i actually currently sneaking back and writing my own django application for some

internal tooling um but i mean that's like i think seven or eight years in well what is what is that

world like right clearly it's engaging enough to keep you occupied 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 django con 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 do you see as the similarities and differences between the two i

mean it's all programming but it's a totally different world um i i don't think it's a

different word actually i okay 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

And 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 kind of conventions, be that like this, we have config files or we pass

it in via environment variables.

And you need useful log lines, especially if you don't 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 direction um we can learn from each other because they are like this structure

structured thing for a system administrator where you say you want your log lines all in

the same format um independent of like when 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 easier to recognize patterns if you don't have to focus on every new logline

and guess the format and so on.

This idea was, I know the term now has just become a sort of postage to marketing,

but this was the idea behind the DevOps movement originally, right? It was that if you get

developers closer to ops they can think with an ops mindset and vice versa yeah um i i honestly

honestly don't don't like dev ops as such because um it's the the idea was there i think but in the

end it turned somewhere so um it's like nowadays it sometimes feels like you don't know enough from

either world um right and i think it's better to have like a developer who's interested in

operations and the system administration who is administrator who is interested in development

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 so it's not like right

i've written it now you deploy it no i'm not going to deploy it throw it back over the wall

several times yeah that's obviously not healthy it's especially when it comes to like um configuration

management where we're using ansible quite a lot 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 world or

using a hsm for um hashing or signing stuff um this 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

so there's talk in the django world sorry there's talk in the django world about um trying to do

something to smooth the road from so the start project template is very 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 to 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?

Hard, hard topic.

The, well, where to even start?

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

But as soon as you start to integrate secret management systems, especially with rotating secrets, 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 change the

password every five minutes and same goes for service discovery.

Like, um, and new connections should always.

resolved 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 um you're going to explain why yeah yeah um so the reason is

we are doing mostly java and in java it's not that bad because you you do have your virtual

machine basically so the java virtual machine and there are usually no program forks or anything 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 and this sub-process automatically inherits all the environment

variables by default, usually. I mean, there might nowadays be some options and Python nowadays also

closes, for instance, open file descriptors by default. But in the earlier days, this all got

inherited to the sub-process. And especially if you're using the sub-process for things like

rendering a pdf file or something and you got an exploit there you have access to all your secrets

and i think every code execute remote code execution that i know tries to look um 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

the 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 it's 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 a file is easier i think it's just too much space

for exploits yeah and also good luck trying to encode i don't know a list or something or

a hash map or any structure in environment variables where you see ugly solutions where

you then have underscore one two three four five and pass through that or json encode and put a

prefix in and it's like ah okay so here's here's my question because um let's sort of follow up to

that because i think for when people starting out and they just hard code the credentials in the

settings file that's a step to move to environment variables is clearly 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 but i think once you have a generic backend you get

all that for free the main question that you usually have to answer is um how how does this

back-end 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 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 this is why every time we have a discussion about it we never make any progress because

yeah but i mean most config systems i know out there for django already support files and

environment variables in some form and usually you can mix and match them

um one thing i ran recently in to was um i'm running 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 and the systemd's got this credentials thing that

you're meant to use on you with that ram it in there it i haven't tried it inside um containers

to be fair okay okay 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

to the service and it has access and in combination with containers it you get very interesting and

great deployment patterns for instance we are also using um socket not socket activation like

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 execute some code that might call out

to the outside world like any document literally like 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 okay so

go on then no you go keep going okay okay so i was going to 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 going to ask

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 the ones that you think yeah no that's that really makes the

difference so we are using ansible a lot really really a lot basically for everything 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 so just for context um the company

I'm working at is a trust center, which is under the EIDAS regulations, where we concern ourselves

with digital signatures and whatnot. And we basically have an uptime of 100%, so 99.999

something or so for the last five years. And this includes basically maintenance and everything.

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

And I like the fact that you can put a database onto Kubernetes and the operator.

So they have this operator pattern, which will upgrade and make backups and everything.

But what happens when the operator goes wrong?

Sure, it's better tested than your usual setup.

But when it goes wrong, you have to fix it anyways.

yeah and the problem with the high nines the uncommon problems become problems right they

happen yeah and so we keep it really simple as as much as possible so we we have ansible we can

deploy a new virtual machine in minutes or actually seconds what it takes to clone it basically

after that ansible 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 something 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 all its ups and downs, like the network routing and everything, but no matter what you use, you have to know the stack.

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

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

Hacksoft is your development partner beyond code.

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, 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 they're handled.

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

I don't think that we had really, really bad security issues.

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 class-based views or was it the password reset view um you

were able to reset a password for any user without the password reset link basically there

it was it really is subtle change but um that that was horrifying i wouldn't have wanted that

on a live site right yeah well but i mean i mean carlton you're are you still you're still on it

carlton yeah yeah i'm still i'm still on the security team yeah hanging hanging on in there

for now i mean i if i think of things that are important but completely hidden um security team

is up there right so yeah the one that comes to mind was um github um had a password hijack

thing with uh with a unicode encoding of emails look like emails of unicorns oh yeah and they

published they published a blog post about how they fixed it in rails and simon charrette was

reading his you know with his coffee and his rss reader the ping them a security list like hey

folks i think we need to do something about this and we will have a quick look we're like oh yes

and then so a hot fix went out i think the very next day and normally django has the um seven day

pre 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 florin says most of them are kind of denial of service ones which probably

you know they're worth fixing but they're questionable or whether an individual

installation is going to get hit this is kind of like 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 processing from my timeline and i mean that also goes a little bit

back to um looking at what other frameworks are doing because um especially with security issues

we are fixing the same security issue in a multitude of frameworks um especially when you

look at flask or so 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's happened once or twice i think and um same goes for php

and Ruby. This is something with all this security posture going around nowadays. We need software

inventories and whatnot. What we first need is to talk with each other and find a common channel

where we can like easily exchange security issue classes basically. Like we've got this kind of

problem, can you look if you also have it? Because chances are that most systems have it and

sometimes you see it in the published 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 yeah or even multi-framework it's difficult enough to you know david lord has

reached out to us a few times and we are in communication with with flask and david over

there but it's difficult enough to handle sort of our own reports because a lot of them you know

there's a lot of traffic to that to the security list and so 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 this you know with seth doing such a

good job there if he could nerd herd us into the same room it's nothing uh a couple million dollars

and a dozen full-time employees can't solve yeah yeah exactly exactly exactly lauren so you said

you were still working on your internal application that 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

and the bits that you think no that's why well part of it is certainly that i know it um i don't

have the time to um play around and learn a new framework just to 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 or dependencies in that sense the the current project has like i think five or so um

and this is massive for me especially this is by no means uh anything against flask or 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 love and think is way way way

superior um than the django orm in some senses 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 one channel for support uh where you don't get told to this is not a problem with

um the form handling but it's with the models different yeah this other channel because this

is all a different company or something like that okay okay 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 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 deck so for me it's most certainly the the low-level tooling like um authentication um

configuration and um there was a third one but this i would like to see in core and um more of

it but i i've never used the sites framework for instance 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 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 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.

This has been the story for Django all along, right?

What's the minimal thing we can do to 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 I say like, yeah, I would feel better if I don't have like 10 libraries of glue code.

I want one security solution and want that to work.

Do you have any thoughts on UV?

I see you have a repo on it.

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

um i'm i've converted pretty much everything to it okay that's a yes yeah yes um but not

well how to put it everyone is complaining every time that 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 um 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 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

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 think i'm switching my package

manager for python yearly so okay okay but i'm in the other school every 20 years well we had

we had hinnick on recently and he's fully on board with uv 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 well and what's helping me currently is that they are um well maybe because

they are funded or just because they are funded um there is a really really quick turnaround on

issues 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 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

Have you looked into it closely

enough to

see into the performance

enhancements because I think

it's obviously written in Rust but I think most of the

enhancements are just

because it's cleverer about

how it searches for packages

it's more aggressive

about caching and things like that

I wonder if you know anything about whether those

speed gains can be brought

into say pip or like you know the community tools um i do think so because um pdm actually

uses the resolver or users can use uv for resolving nowadays um so it's certainly doable

but i'm not sure if the resolver itself um i mean the resolver certainly plays part in it but i'm

just guessing i haven't profiled it but what i do know is that there is aggressive really really

aggressive caching going on to the extent like when your 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 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

so okay okay cool cool cool i have a question this is probably just because i started working

at jet brains which makes pycharm intellij i'm curious what what text editor id do you like to

use these days and why um i guess out of habit uh visual studio code um i was using vim for a long

time before but the um yeah the easy let's put it that way the easy integration of auto completion

and everything uh won me over i i do know that i can do everything with vim 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'd have a default

configuration there and once you use vim on your local laptop and connect to a server and the

configuration is different there it's it stops becoming viable this this is one of the reason

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 a

an unhappy user so to say because um i'm not going or i can't justify paying i'm maybe i could

I don't know what the policies are or if it's possible to pay for it, but with all these

Python plugins becoming more and more closed source and the digital right management stuff

around it, I'm not too happy about it.

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

And also, I mean, I know we do use JetBrains here and there, but, and correct me if I'm

wrong.

Last time I looked at it, it was 10 years ago.

But I think it's still like you have one program for one language.

And in Visual Studio Code, I have some plugins and it works well enough.

And I'm switching between five languages a day.

So I wanted the consistency.

That's a common thing out there.

There is some truth in it.

I think it's not totally true.

for example, if you use PyCharm for Python, it also pulls in WebStorm, which has support for

JavaScript, TypeScript, HTML, CSS. So, you know, if you want to hop over to Java, can't do that as

easily. So there's, I think JetBrains doesn't talk about that, the bundling, partly because

there's the pro and the free version. So it's, it's mostly true. I mean, there's, it's interesting

that 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 JetBrains is a little more like Django.

It's all in-house. I mean, under the hood, it's basically the IntelliJ Java engine. So there's

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 jango-y um but 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 and i mean for me it's not i'm not doing much

editing right 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 so so mostly

uh yammer scripts or yammer files and it's i need most i mostly need syntax highlighting and

that's about it have you tried um have you tried zed at all 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 clop

who's involved in the Django community.

He's, yeah, it's public.

He just started working there part-time.

That's interesting.

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, Cursor.

There's sort of these two extremes of like,

have AI, have full integration agents and stuff.

And then there's also, I just want a text editor IDE

with some syntax highlighting that isn't slow.

right yeah 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

just mentioning the ai i have because i imagine you can't go near it really at work because you

can't risk you can't risk errors i i don't know um i'm i'm not involved in those discussions

um i actually don't know aside from 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

it would still be your fault 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 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 and AI can help you iterate faster and I'm not sure if it maybe it was Guido

in his early days after joining Microsoft or something like that it 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 um an ide doesn't

help you find stuff all the time you still need to know where to go looking and i 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 sub projects like

django drf or django ninja which re-import and so so 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 wouldn't be too afraid of it.

Okay, fair enough.

I was just watching,

Guido had an interview

with Lex Friedman

a couple of years ago

in his podcast

talking about text editors.

And Guido was saying

that he used,

for a time,

he used PyCharm

specifically just for the search,

but then he would go back

into, I forget,

Vim or Emacs,

something, you know,

now VS Code.

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 pie charm 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 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 yeah and i mean even whether you're better or not

it honestly doesn't matter 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 also performs better and i'm just not sure if

it's worth it and what what came all out for me is that this language server protocol so all those

generic integrations into the editors which are not always that generic but those helped a lot

and 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 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 chat brains for it right but if you take an interface

it can be anything so i'm i reckon that the the main difference there between the different

grades of autocomplete you get is the static typing of on the language it's a 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 um i i'm honestly not sure but because um i think it's

it's an incredible tool. Personally, I'm now at the stage where I would like to see it.

I'm not sure how to start, right? Because, for instance, we need to be able to type the low-level

objects first and then kind of build up from that. So I don't think that an approach where we

just annotate new code is going to be that helpful especially we would want to have like

type checking in ci that verifies that we're using it correctly and if 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 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 it is

really hard to get started especially um like when you say unicode and text you have like um

be lenient in what you accept, but you have to be 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 far do you go? 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 and i've had a case so i know some version of django let's

call it two point something made allowed hosts it said no it has to be i did a check where allowed

host had to be a list and i'm like i've got a project from the old days that has an iterator

there and it's just broken and like ah why yeah that's so certainly type checking is is hard um

i i really see the benefits especially in in smaller projects um at one company where i work

we had like um communication with phone systems like in a hotel guest check-in check out and

stuff like that and those are phone systems from really old age basically where you have serial

cable updated to ethernet 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

with python and it was really hard for me to write tests for such a thing because the code was

Async and I tried to write it with this SANS IO approach, but in the end, for some projects I just can't justify writing the tests. 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 mistakes i think be that typos i mean the the ids are already good with typos per se but

everything else like trying to add an integer to a list or something with the wrong operands

this is really really great and it shouldn't mean that you don't have to test anymore but

you you don't have to test that much i would say because previously you have you you're taking an

object basically and you either have to document very carefully what the function actually

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 yeah and with a compiled language you you have that 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 but it's still not easy no okay so i've got one more sort

of question i want to ask you is it as a you know but 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 a lot of desire to push django forward 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 that's one of those where i think i don't have an answer

um part of me not being this active with django anymore is um probably kind of

i wouldn't call it burnout but um it's this this inertia that exists where 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

um one idea that just came to mind literally now so no no idea if it's uh viable is to ask

other communities like rails or spring to talk about exactly this on django conferences

that they provide their experience how they managed to move beyond such a point or maybe

they didn't have this point this problem at all and this would give us an outside perspective

I think we're doing better recently than we did a year or two years ago, especially with the new steering council as well, because I think we need to make choices now.

and i'm i'm happy if if someone makes those choices and 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

um 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 duplicate code for every 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 won't see Django as a general async framework,

especially with this handling

or how the async code in Python generally looks.

I mean, it's not so bad nowadays,

but I have bad memories of the callback health

in JavaScript and to some extent in Quisted,

which really makes it hard to follow the code.

And this is probably because I stayed away from it.

And also, I don't need it.

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 love your idea of having someone from the other communities come to a DjangoCon and speak.

I mean, we, for example, we had David Hennemeyer-Henson on this podcast early on.

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 Hennemeyer-Henson.

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 kind of the difference is that all these other ones we're competing

against, you know, FastAPI, it's Sebastian in charge.

They do have a little bit more of the BDFL, not they do sort of, they definitely do, so

they can move faster, right?

So I think the question is, over the long term, what happens when those companies or

people want to step down?

But, you know, that's, 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. Yeah. And I also don't imagine that spring or something is going away soon because

there are so many big, really, really big companies using it. So there will always be

someone picking it up. If they end up in the same situation as Django, then I don't know, but

there is enough incentive and money behind it, I guess.

Oh, but if we had, you know, I don't know, if Instagram had decided to, like, put a ton of money into Django, like, it would move faster.

It would still be a community, right?

Like, so there's more the question of VMware or some for-profit thing that pushes it as opposed to 100% community.

Would that actually be true?

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.

Like what I could imagine, for instance, is like if Instagram employed relatively early on 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 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 orm to this situation or something

like that it's an ongoing thing yeah absolutely i've got to say something like i think for me

it's very much we the trouble with having everything in in core all together and everything

going through core and everybody wants to get their feature into core is that everybody's then

having trying to have one conversation and it ends up with too many people having the same

conversation and what would for me what i'm trying to think of ways without you know taking out the

orm so you know you'd have to install that stuff but find a way where we can just modularize

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've kind of feel like

we need to do something in that direction what the boost library is doing it's i mean it's a c++

library they have this um git master repo where they have submodules for every submodule basically

um but i think this would be kind of hard for django because like the the components are so

so intermingled and it we don't have clear boundaries right and we don't want them in

the end because that's what makes django great that the form framework integrates so well with

the models and um i'm not sure if it gets better if we have more boundaries in between um as

little small slight they are but yeah no but exactly so what what was the reason you use it

you use it because of that integration that it is you know it's got that Django feel right

I think we're basically up on time was there anything you wanted to mention or

you wanted us to ask you while you have a microphone

um no I think we've covered quite a lot um well actually what what we didn't talk about no

we are going to talk about that now um how this that project template uh looks like which is what

actually brought us in here right yeah because we were talking about it on the social medias

exactly and so well just as a quick recap so that there are always those discussions what

start project and everything um should include or should not include and i think it depends a

bit on what you're doing right um we we already have start project templates and there is cookie

cutter and django and copier out there which which i really like because it allows you to

release new versions of your template and then update existing projects

and you obviously sometimes get conflicts then but this provides some

nice way to actually update your projects without manually reapplying all your changes

And what I'm doing is basically I'm shipping applications, right?

I'm not in an area where I say, okay, this is the application added to your settings

file and I'm shipping complete application like Netbox or maybe Venueless ships.

And what I found useful is that you could just use that project and then immediately

at this generated project as installed application into your setting uh into your settings file and

this solely means 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 as on on a sub directory sub package basis because it's 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

dot core application and oversight dot user and oversight dot 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 have this namespacing and we can use this and i don't see any any reason anymore for this

project a project for me so in in django speak is basically a settings file or not even that

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 okay so it's like the single folder right the 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 these 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 and it would make tutorials quite a bit

easier i think i'm i mean we would change the start project template probably to account for

that so not just add the application to the project to install applications but also like

provide a dummy models.py and tests.py which we don't use and maybe i don't know i'm sometimes

moving the the whisky module into a sub package then because it's it's a little bit ugly on the

top level right but that's whatever you prefer i mean i think for especially for newcomers if you

so i have a open source thing called lithium now that was django x that basically just gives you

django all off and a little bit of config 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, but have a way to do

that. You know, if I, you know, if I could go work on Django for like a year, I would add those

happily and just put them in. Cause I think that would help newcomers for sure.

I mean, I started doing that with a copier template where you could provide in.

So copier asks you a few things on startup and you can define those questions and like, do you want a bootstrap template?

Do you want this JavaScript integration?

So basically provide a kitchen sink Django template.

I stopped doing that because when I'm using Django, I use this one CSS framework.

use this one javascript library and um i think in in all those generics uh there are days

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 well if we were you know and

If we were Laravel, we'd just charge for them, you know, so.

Right, right, right.

But I think there are also some Django software as a service templates where you click together.

Like I want to include authentication.

I want to include Vault for secrets management and everything.

And they are selling.

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

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

Well, it's it's I mean, Corey, Corey Zhu has SAS Pegasus.

He's, I believe, working on that full time.

So that's working.

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

My sense is that it seems people want the SAS integration more than they want the rest of it.

Right.

But once you download the code, probably licensing is stopping you from using it for another project.

But you get the ideas, right, how such a thing is built after you paid for the first one.

So I don't necessarily see it scaling that well inside one company that you can sell it 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.

well we're going over time i think it's like it's people it's an education thing people use i mean

this has been done other frameworks where people use a sass starter thing in rails to get going

and then fill in the details i think it works a lot like that actually for people but

yeah i don't know i don't know exactly just let me just finish this topic there is a depth that

we're hopefully going to push forward in the 6.0 or 1 timescale

to update the start project template,

make it a bit simpler 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, 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 blog.

There's a wagtail example.

There's a who knows what.

Yeah, hopefully it's just the templates currently are a little bit hard to use.

If you use non-standard files, you have to include it in the command.

And that's what Copier gave me.

And it's like reinventing the wheel.

Why improve Django in this direction if we can use Cookiecutter or Copier?

I don't know.

Maybe use something else.

Yeah, okay.

Well, that's a good point.

We probably will leave it at that and hash it out.

Yes, yes, let's do that.

So Florian, thank you for coming on.

When we first started this podcast,

you were one of the names we wanted to have on

and six years later, here you are.

We finally did it.

Yeah, I'm good at escaping those things.

Yeah, well, that's probably why you're productive.

So again, thank you for making the time.

We'll have links to everything in the show notes,

chat, jangochat.com, and we'll see everyone next time.

Bye-bye.

See you next time.

Thank you.

Bye-bye.

This episode was sponsored by Hacksoft, your Django development partner beyond code.

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