Transcript: Git and Django 5.0 - Adam Johnson

Hi, welcome to another episode of Django Chat, podcast on the Django Web Framework.

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

Hello, Will.

And we're very pleased to welcome back Adam Johnson, who's well known to many in the Django

community, and we're going to talk about his new book on Git.

Welcome, Adam.

Hello.

Thank you for inviting me on.

And I've got to say, snap, Carlton and I are both wearing Django.social t-shirts.

You are, you are.

Well, what is that?

Tell people what that is.

It's a series of social meetups held globally, I guess now.

I think there's going to be one at DjangoCon US.

Or am I?

I'm guessing here, I think.

But yeah, John Gould, a recruiter here in the UK for Django Specific, who's just a great

member of the community, giving back a lot, hosting these events, giving back to the DSF.

so django social is his project for running meetups socially everywhere and he's also

ready to help anyone who who wants to jump on and start a meetup in their city

for socializing with django developers i've thought about doing one in me but i don't know

if there are any django developers near me so if you if you're a django developer near me on the

cost of rabbit let me know and then we'll do a django social two-person django social i've been

emailing with john because i'm looking forward to seeing him at jango con us are you attending

adam or you're not right only remotely this year yeah okay one fair enough fair enough we'll get

there yeah yeah yeah um all right so let's talk about git and may actually since we have you on

adam with all your many hats steering council maybe this could also be an opportunity to talk

about 5.0 because we just as we're recording the feature feature freeze just went into effect i

believe and the alpha release went out uh yes 15 hours ago so let me let me let me defer to the two

of you what what are what are you all excited about that's coming out in five oh go on am you're

the guest you go first okay uh i i've i've listed three features that i wanted to highlight the

first would be generated field which um lilyfoot and others pushed through and myers got it in at

the last minute this last week this is a database field that is computed in the database from some

calculation across other database fields so classic example would be you have a user with

a first name and a last name but for some reason you want to be able to search across their full

name you can create a virtual field there that is a combination of those two and then you can

write a query set that queries against people's full names so like if you've got to type a head

search you might be able to let someone type part of any part of their name and it will search across

all of it without query set tricks it's all just done once in the model so a way of um um how should

i say uh removing some of those annotations that you might have sprinkled about various times you

go on that was one then what was two okay uh the db default yes which is for defaults computed in

the database rather than by django which is i think it was the oldest open ticket when it got

merged like number 470 when new tickets are in the 33 000s um this is big because having your

database as a single source of truth for things like timestamps is is very useful it also means

django doesn't need to do anything extra before saving such fields you can get the database to

do the computation if necessary and like it ties in for me with a lot with the constraints works

that that's gone on so with constraints instead of just having say validation at the form layer

you're able to make the database have those and then that feeds back up to the form layer now

which is super cool but then to have constraints and then database dbs uh database defaults as

well that's like ah yeah brilliant it's just great to see django like expanding to like cover

everything that databases can do and have been able to do for years or decades in some cases

like database defaults yeah the the related one that didn't quite make it but i'm thinking might

for 5.1 is cascades which is or you know the on delete clauses to have those at the database level

there's a pr open for that but i think it needs a bit more work to get it over the line yeah

yeah i had a look at it but yeah that would be cool as well because it would save like this

giant cost that we often pay when deleting in django because django pulls everything in itself

before it deletes it whereas just letting the database do that work and clean out the disk

it's a lot faster okay and then your third exciting one uh it's a bit more niche but it's

the dash dash durations flag for the test runner in python 3.12 python 3.12 added this and now

django 5.0 exposes it through its wrapper that's just a great way of seeing like what are your

slowest tests you can say dash dash durations 10 or show your your 10 slowest tests and then

you know where to work if you're trying to uh speed up your django test dear listener you may

not know adam has a book on speeding up the django test so you should uh check that out if you haven't

seen it already i don't need an update yeah i was actually just looking through that last week

because i was stuck on something and i was like wait a minute i have a book on this i've read and

you know you had some good advice so it's worth rereading oh cool thanks is there enough i guess

you're working on the git book that we're going to talk about um but have you started work on the

update there or that's sort of later on i've uh i've done some bits as i go like when i see

something has changed in the django ecosystem and it's just a few paragraphs to change i do that but

i haven't pushed those updates yet because i'd like to compile with the latest sphinx and whatever

so that EPUBs can come out in the best way they can.

That has been an issue in the past with older versions.

Okay.

I can relate, yeah.

It's hard.

It's sort of like a chore to put an actual book out,

and so there's all these updates that if it were just a website,

you could just kind of do.

Yeah.

It's even worse when you have paperback books.

But you smartly avoid all that.

Lazily avoid all that, yeah.

Yeah, wow.

So yeah, so maybe that's...

Can I just throw in one?

Before we move on from 5.9,

I just want to throw in one extra feature there,

which is the field, the form rendering

has grown this new attribute,

which is as field group.

So you know how when you render a form field,

it's got like the actual input,

like the text input where you enter your data,

but it'll have a label and then it'll have errors

and then it'll have help text and all those things and um that's all great but when you if

you need to customize your form template having to do all those for each one is a kind of bit of a

pain so um bound field now has this as field group helper which will render that a specific template

for groups them all together which means if you want to customize your form layout you kind of

just do field as field group field as field and you do the surrounding markup maybe you want to

use a field set or whatever it just makes writing those custom forms um that much smoother or that

much quicker i'm really i'm excited about that so anyway and i'll just shout out um david's david

smith gave a really great talk at jangle con europe about that transition and what to expect

that you can find on the jangle con europe youtube channel but i would recommend that if

the docs aren't fully sufficient as they were not for me but his talk made it very clear

yeah stellar talk stellar talk okay so get

so you know let me ask you now we'll come on easy

get it together yeah let's make the puns

well so i it's hard to know you know the level of people listening to this podcast but

get is a big deal maybe what's the quick why is it worth its own book of performance enhancements

or just experience enhancements right we all use it but what what more can there be beyond you know

git status git add git change i mean that's exactly like the the story of where this book

came from i think for a lot of us like i mean git is git is not the work right the work is like

building your website and it's a thing that's there that's useful but it's also like in the

way of each time you make a change so i think um it naturally becomes something you learn enough

to get going and then everyone like stops i think that's also a problem from the git docs perspective

their docs are incredibly dry low level use a lot of terms they mix up terms because there's like

three different names for a commit and so it's quite hard i meant to say commit i meant to say

commit not change but it is also called a change a change set a revision like various other names

in the git docs is super confusing um so like i found that like there's this kind of um genre of

hit tweet where a developer shares like change this one thing in your git config and then it

gets like 10 000 likes because like oh wow that just fixes this thing where i had to annoyingly

type a command every time and i just kind of like kept seeing these and i like i changed my own

config over the last nine years i've used git 10 10 years um but there's no like central place i

found that would explain all these to a new person like you can throw them at your git config but

that's not really a help like what does this actually do so this book is basically my attempt

to compile all of that stuff that i've seen uh into one series of logical short explanations

lovely yeah well maybe what's a what's an what's one example of something that

you now use all the time that like saves you time improves performance like what are some of the

like what are we doing wrong right if we're just using the main the main big three and like that's

enough like one one small thing uh is auto correct so if you've ever typed git commit with one m

it by default just says i don't know what you're talking about maybe you meant commit with two m's

but try again but the auto correct feature you can actually switch it so it like goes did you

mean commit and you can just press yes or you can actually have it go immediately like there's only

one thing close enough it's commit let's just do that so that's like one simple tweak and that'll

actually save you maybe an hour a year an hour a month i don't know how well you type

that's a bit you know seat the pants isn't it automatically correcting your type i think

I haven't had much of it yet.

Well, I like that, you know, we can dive in.

One of your chapters is on aliases because this is something I find that, you know, beginners have no idea about.

And if you see someone do a YouTube video or something, everyone has a slightly different alias and they just go the speed of they just blast through.

And it's completely uncomprehensible for a beginner.

So those are very exciting.

And like, maybe tell us about that chapter, because, you know, like for me, like I just

do GS for get status, you know, all these little things to your point, they, they do

save you real time, but it's just like, how do you learn about them other than peering

over the shoulder of someone doing it or seeing some random video?

Yeah.

Aliases are a great one because they shorten your typing significantly, which also reduces

the chance for typos.

There's like two kinds of aliases I cover in the book.

there's the shell aliases and the git aliases.

So shell aliases are set up in your bash or zsh config,

and they can map to any command.

You can basically say for this,

when I type this series of characters, actually do this.

And that can be five commands in a chain

or just one command with a bunch of arguments

or something like that.

In the book, I actually recommend pulling in

Oh My Zed Shell's aliases, even if you don't use Oh My Zed Shell,

because they're a curated standard bunch of aliases.

And I've helped actually contribute to those in the writing of the book.

Why does that not surprise me, Adam?

A few things as I was writing just kind of annoyed me.

But yeah, they've got about...

300 aliases, you probably only need 20 to 30 of them

on a day-to-day basis.

But if you spend the time just to learn those,

then you could go way faster.

You'll be typing like GC instead of git commit,

GC exclamation mark for git commit dash dash amend,

and so on.

The other kind of alias is the git alias.

That's something you put in your git config.

And that's where you have to type git space and then your alias.

That's more useful for wrapping up slightly larger commands with a single word.

So I have one in the book that's like git switch recent,

which helps you switch to recent branches that you've committed to.

It lists them all in order and shows a select.

I've got a git alias to check out a PR, check out the branch for the PR.

Basically, I just couldn't work without it.

like git pr and then the number of the pr and it just goes and fetches the branch and and whatnot

and without that you have to do well what's the url what's the you know what's the remote it's

just a lot of faff whereas you know git pr number damn and yeah i literally could yeah that's sounds

sounds like a mastodon tweet carl i don't like hit tweets

just giving love to aliases yeah well yeah and it's it's interesting i i've been mentoring

someone recently and it's been good for me to just re-see i'm like well don't you know about

this don't you know about that and you know i just you just forget what's what we know and it's like

how would they actually learn that right there's no and aliases are one of the ones um yeah that

huge time saver that you may not know about and as you said also very accident prone like you just

that's the thing that when i first got into coding a while ago now i thought that coders

had like perfect typing skills and now i realize they're like the worst it's just they hit tab and

have all these linting and tools and you know it's it's almost worse than than writers with the

grammar yeah but now you have grammarly and stuff but you know it's oh yeah you gotta you gotta do

it perfect perfect yeah thanks no there's all these thanks for the grammarly recommendation

that like it's really helped this book i was finding i wasn't putting commas in the right

places oh my god well don't let's not yeah they're total common nazis yeah the con the commas the

commas thing is really you know to that's the one area where i consistently am like no no no no i

don't need a comma around every every comma single comma word but anyways well maybe that ties in so

one of your sections is book-driven development i think you've talked about this before but

what is this concept how does that manifest for you because uh not how i write my books but maybe

i should uh well for me a book is a bit more of a broad project that i just try and have fun with

and all the things i'm talking about are open source so it means i can dive in and improve

them in some way if i spot something on the way um i this is how i've become a git contributor

through this book uh which is a bit of a gauntlet to get a patch actually into git it's not done on

github it's done on the mailing list and it goes through your email inbox only so jango's not so

bad then no no in comparison how okay just on that how does that email flow with git work because

was the original workflow right it was designed to send patches to linus basically and how did

that go i mean how what's that like so the the tooling built into git for this is that it can

actually send an email it has a command to format a patch and then you attach your text to that and

it sends us an email using the smtp setup on your laptop on your computer i didn't use that

i didn't want to like set up all that so i used this thing they added a few years ago for making

a pull request on github and converting that to an email so i still had to chase up my comments

on email but at least i got to submit it the kind of normal way to begin with um it's all right like

receiving comments over email is pretty much how i'd use github initially anyway it's a bit all

over the place at reading an email that's like got strips of your text of your patch with comments

underneath it's a little bit harder to go through you can't just check the box done that right okay

resolve conversation but functionally it's all similar um github's just a much better ui for

doing that than plain text email that's the other thing getting an email onto this it has to be

plain text so you've got to go check a box on gmail or whatever and if you don't send it plain

text you don't really get an error message like oops yeah because it just goes into the you want

to know okay carol anyway i just wanted to know because i did i i was how did that come up somebody

tooted at me about how this was the this was the one true way and i was like okay i've never done

it but maybe it is i i think the git community has uh often discussed that it's slowing down

contribution quite a bit and this kind of halfway house is where they've managed to get

everyone to agree to because a lot of people who do it are very happy with their command line email

client and their command line git and everything it's okay it's it it's functional and that's all

it needs to be i think it's good for the git project long term that it isn't tied onto github

or any other provider yeah i mean that's my my sort of one concern is that github slowly gets

more and more dominant and more and more areas a sort of well what is the alternative what happens

if github becomes somewhere we need to leave are we able to yeah and every year they do something

that causes another wave of people to

decry that this is the final straw

but it hasn't

actually been yet

yeah I think it'll be

interesting what the future is for

Git and Git hosts

I think Git will outlast GitHub

by some margin

still

and I think whatever comes next in terms

of source control will be one of these

Git compatible tools

that still uses Git

as the backend for storing it

that just presents a nice command line interface and whatever.

There are a few in the works out there.

Yeah, so that's maybe a fun question to think,

put your tinfoil hat on.

How does Git get replaced or something?

What could it do that it can't?

Or what structurally, are there any obvious things structurally

that if they're going to redo it now from scratch,

you would be changed about its architecture or just how it's used?

I think the big thing with Git is that it

tried to be very, very simple with its object database,

everything stored in files.

And scaling that has turned out to be very hard.

I've dived into recent changes in Git.

They're all about modifying these file-based data

structures to scale better, whereas Fossil,

which is a competitor, that's the SQLite source control,

that stores everything in SQLite.

And so scaling that would be a matter of optimizing

a few SQL queries.

You don't need to rewrite all the data structures.

Maybe optimize some tables, but that's

a very well-known kind of space of how we get

SQL databases going faster.

Whereas it gets to a lot of low level,

OK, now we need to build a special index file

for this particular use case.

Now we need to build a special thing.

And they absolutely never take on a dependency like SQLite

either, because they want to work on every platform that only has a C compiler.

Well, let's, you know, since we have you on to talk about Git, let's talk about,

you know, Git reset keep. That's a little tip you have. Like, what can we say about that?

Okay, so do you know what Git reset keep is?

No.

No, no, no, no. I know what Git reset is. So Git reset will take your working tree and

reset it back to how it was before you made some horrible mistakes. But I don't know the

keep flagged there adam so yeah well git reset kind of does two things it's the way i would talk

about it one is it can unstage a file so you've clicked you've done git add on a file it's the

opposite of that um but the other thing is if you pass it a flag and a commit uh id or name like a

branch name it will move the current branch to point to that one and then people typically learn

about the dash dash soft and the dash dash hard options.

The soft one, it keeps the changes.

So you can get reset soft to a previous commit,

but that will keep the files in the current state.

So you're ready to recommit those changes.

Perhaps you meant to put them on a different branch.

Perhaps you meant to make some tweaks.

So you can redo the commit you just did or the last three

commits you just did in one or something like that.

And then hard is for when you want to throw away changes.

It moves the current branch and doesn't keep the changes.

The problem I found...

Yeah, I remember...

How about you?

I just see hard is the one where I'm like,

oh my God, I get a little nervous whenever I do,

or try not to use it, but sometimes you just get lazy.

Right, like it's this thing that you're like,

it's going to throw away everything.

So git reset keep is like a better version of hard

because what hard does is it not only moves the current branch

to point to some other commit,

It also throws away everything that you haven't committed yet.

It's like a side effect that you don't really want most of the time.

So if you use dash dash keep,

then you can have some test file you've modified

and then reset to, say you're resetting to origin slash the current branch

to undo whatever fixes you've attempted locally to go again.

So you can do that and keep the working changes.

And I think this is quite important

because the only data that Git doesn't let you recover

is stuff that you haven't committed yet.

So if you have local changes you haven't committed,

Keep keeps them around, whereas Hard throws them away.

That's quite handy because sometimes you try, for instance,

made those changes in order to bisect an error,

and then you try and check out the bisector,

and you're like, ah, I've now got to, in between each Git change,

you have to take the changes out, change the repo,

and then put them back in.

That's a pack.

Let's see if you can do this.

Exactly.

That's one of the things about Git,

and maybe there's a solution to this,

is if there's nothing in it, Git won't track it.

So if you create a folder for static files,

like images, and you don't have any images yet,

and then you try to track it or do anything with it,

you have to do this .keep or just put in a dummy file.

That's something that has tripped me up in the past,

and I get questions about that.

people yeah if it's not if it doesn't have anything in it gets not going to automatically

track it if it's empty right like gets gets data model only tracks files and that kind of makes

sense if you think about it because you wouldn't want it to like keep around empty folders that

have had all their files deleted you wouldn't want to have to worry about file folder permissions as

well as file permissions um things like that um yeah so i did write a blog post about this i guess

that's why you're asking a question or no to be honest i don't recall the blog post i just have

a thing in my book book on this and it causes problems for people and so that's why i added

one of the updates like dot keep or blank files because all right this is what it's a which is to

say it's a common thing oh yesterday okay i thought that's why you're asking no that would

have been that would have been smart of me all right yeah there is this uh practice of adding a

blank file called dot git keep or something but that still requires you to oh my god yeah i i

swear to god i i didn't see this it requires you to still add like a git ignore rule for everything

else in that folder um but you can actually do this by just dropping a git ignore file in the

folder you want to keep around, and writing a couple rules.

The first rule is star, meaning ignore everything

in this folder.

And the second rule is exclamation mark dot get

ignore to say but don't ignore this dot git ignore file right yeah yeah actually i was thinking of

an older like an older dot keep not not not git keep but actually um something you promoted which

um i was like oh yeah that's important is the work that um brett cannon just did on python 312

right we're gonna have automatic um git ignores for the virtual environment i believe oh yeah

Yeah, that's a good feature.

Very happy to see that got accepted and merged.

Yeah, Python's virtual environments,

if you use the virtualenv package, which

was the original way to create a virtual environment,

that added, at some point, this feature

that drops a .gitignore file with just the rule star,

meaning ignore everything in this directory

into each virtual environment.

So you can't commit those virtual environments

and push them to GitHub, which is a classic beginner way

of duplicating code.

And now that's been added for Python 3.13

in the VEMV module, the built-in version of virtual env.

So that will save a lot of virtual environments

getting committed.

And it'll also mean we can all remove a rule from our git

ignore files from that point on.

MARK MANDELMANN, I know, I hate just copying.

I don't like to just copy over the Python one from GitHub,

because it's so long but there's always like 10 different things every new project i need to just

put in by default like um and maybe janko could of course that's controversial is there any debate

on that is it it's not a debate you want to have because if it can't like someone will mention it

and then it's just like not a conversation that ever goes well so it's better just not to mention

okay well you you two would know you two would know i haven't i haven't no but like i i assume

as i assume as much what happens with sort of esoteric conversations with jango is because

there's so many users with such diverse um requirements that what works for the sort of

50 case it's going to upset an awful lot of people and it's like and so these kind of little changes

which look little and they should you think oh that doesn't matter we just do that but actually

a lot of people get upset about it it's like no okay we just won't do that so jango's um default

um git ignore is quite minimal or i don't even has one in the default template and you know

and but even in like in the repo we don't put every possible git ignore in there so you know

you might use um pycharm and i might use vs code you might use you know some other one and so

we don't put like the git ignores in the django repo for every different ide we say look use the

local git exclude option now adams you've got a different take on the git exclude you you saw

i saw a post you did a few weeks ago on uh well you've you can create a global ignore file

for all of the repos you work on so if you're using pycharm ignore pycharm across every repo

you ever work on and then don't bother any adding stuff to every repo you work on um that's in the

book but it's also a blog post so i mean the with the blogging i mean you because you blog quite a

lot right and that's why i thought you were going to do a book on typewriting typing because you

just you know a whole series of blog posts on typing well adam's going to do a book on this

and you you didn't at the time good you know whatever reasons but like you've you've blogged

quite a lot to to um what first draft it or to to think through your ideas clarify your ideas

just for fun i guess it's because i think i'm quite forgetful okay

you just want to google yourself you're like what is this thing and then you phrase it exactly as

the title of your blog post because that's how you think right i find that right even if it's

a topic with lots of stuff like i always you know future me phrases it like past me and then i'm

like oh um yeah and i guess for me it's also a way of like gaining confidence in what i'm doing

Like if I'm about to make some project-wide change

on a client project, I'm always like,

I should write up exactly what I think I'm about to do.

And then by the end of it, I've got a blog post

because I've found all the potential flaws

and gone like, okay, here's how you use this tool in Django.

Here's the problems that I found doing it.

So it's like a way of tricking yourself into writing a spec.

I wanted to ask you because like Carlton, and maybe even actually more than Carlton, maybe you have so many third party packages that you both maintain and new ones that you work on. Like, I mean, let me just pick one. I think that you took over cores headers, like, can't really do most API's without this.

like what i don't talk to i guess talk to me about like what how do you manage all that how do you

how big a burden is it for you to manage things like that that are just core pieces of the

infrastructure of django and then i know you have some newer some newer ones as well

um i guess i just like collecting them and one issue that always frustrated me coming into the

django ecosystem i'm working with it for a few years was that these packages were sitting there

they had a lot of stars they had a lot of downloads but the maintainer wasn't around

anymore the pull requests were piling up the uncertainty it added to like am i going to be

safe upgrading to the next version of django with this package oh it seems to throw a warning maybe

it has a problem how will we ever fix this um i just decided to like carve out my own little niche

of like the packages i own i'm always going to try and keep them up to date for python and django

and maybe i'm not like super active on adding features or um making them like more modern in

some way or another but i want to keep them working that's like my baseline and to reach

that goal i've i've like normalized them all to like a single uniform template and then i can

script editing them so with the django 5.0 alpha i decided to test them all it took me about 60

minutes of work this morning to actually add that to these 16 packages that i have yeah i just looked

through and it said you updated them all like what yeah this morning i was like yeah yeah and

you've mentioned before like i think maybe the conference how you did that because otherwise

you just couldn't like it's just such right it's too much and every other project the maintainers

have picked some slightly different tooling they've gone for poetry rather than setup tools

they've gone for testing with travis or still using travis when travis has stopped working or

they're all in this kind of like landscape of different tooling that is very hard to navigate

and i do go and make you know new django version pull requests to packages that my client projects

depend on but it it's a lot more work figuring out where all the pieces are like where do i write

django 5.0 where do i write the update on the docs um so yeah keeping them uniform is like my secret

weapon there my experience is very similar i took on django filter why because i was using it it was

basically unmaintained i needed i needed to know it was going to work same with crispy forms i was

using it in projects it was basically unmaintained it was going to break and you know somebody had

to take that on so i took that you know so i want um you know that was how i did it i look at you

and what you do with the number of projects you maintain i'm like yes that's that's the way so

slowly you know it's not something i'm gonna do on the weekend but slowly okay can i systematize

slightly more so that those small differences between the packages slowly go away and then

this what's this tool all repos is the tool you use right is it i use one called my repos there

is or repos okay i wouldn't necessarily recommend my repos it's right okay just a way of running

shell commands in each of many directories but like you've used this the basic idea is yeah

that you can run the same commands on multiple repos and that's you know that's an awesome thing

so i need to get to there i'm not there yet but you know mostly it's like okay we're going to use

tox we're going to use github actions we're going to declare the tox file this way you know that

sort of thing well i was just working on a new project and it was i was like god everything is

so slow and buggy and it's because i hadn't added uh browser reload one of the packages you have

and there's just so many i mean i you know you wrote a book on improving your django developer

experience but you know when you just don't have all the tools that we we have and set up it's just

like you know it's like one hand behind your back just uh all you know don't having pre-commit like

i mean it's just hard because there's but yeah there's there's your book right it's just like a

a bunch of setup that takes time and like why am i doing this and same with you know optimizing

your git right but once you do you just don't realize how much faster you can go right um with

these tools yeah like the defaults are good but if you're spending hours a week doing this then

it's always worth committing some small percentage to improving how fast you go in the actual work

ours amen so i've gone well i just wanted to ask you in the notes about the git book you've got

this um you mentioned pigments git now that's for highlighting right so tell us about that because

that's that tweaks my sort of what's that um pigments is the popular python-based uh code

formatter um i think github used it even until they made a ruby version of the same thing um

but uh yeah pigments is like got a lot of highlighting rules it can highlight python

code shell code like a hundred other languages built in but there's nothing for like git related

files and so i was finding that my git blog posts and my book were very dreary it's all black and

white even when they're already about yeah it's already about git

so i i wrote something that tries to restore some of the color that you would see when using git

or using um git syntax highlighters in your editor for things like the commit message file

so it makes the book a little bit more realistic and hopefully a bit easier on the eyeballs

what editor or id do you like these days i forget i'm not sure if i've used sublime text

since 2012 and no plans on changing there you go for me the big selling point is it's got python

that you can extend it with so i've written a few small extensions that do what i want and sometimes

i've got some large refactoring i'll write an extension that does a few different editor

commands for me so it's not quite the same as like just regex replacing everything in your

code you're stepping through still maybe you have to type something at each step but

that's a cool middle ground i think pre-commit i think i wrote a blog post on this because i was

fiddling around with it for a reason um you've written a bunch on this i think and there's

some stuff on get and pre-commit like what would be your little soundbite on on that like what

maybe for people listening what is pre-commit and why is it you know worth a mention in your book

uh yeah pre-commit is an awesome tool for running all your code quality tools um i've actually

written a chapter on it in both the Django DX book and now the Git DX book, which is much less

Python Django specific. The cool thing about it is that it's not just a way of running tools. It

is also a kind of package manager. So you can throw in a tool that uses the Rust or Go or

JavaScript or Python tool chains, and the user does not need to have those installed. It knows

how to bootstrap entirely each of these programming languages, package managers, and then the tools

from scratch so um very easy to throw in one extra tool that is maybe not something that

not using a language anyone in your team is using but it just works and yeah it's stability and

flexibility the sheer number of tools yeah it all adds up to like a pretty good developer experience

do you um you mentioned rust do you like rough are you still on the flake 8 bandwagon i know

I know you have some new Flakate packages

you've been working on.

I think rough is a cool tool.

I use Flakate still.

I've never had the need for extra speed.

I think the unification aspect is very interesting.

and probably will help a lot of projects,

especially if you're getting to a larger scale,

just keeping everything managed.

We'll see where it goes,

because I'm more of a fan of open-source community managed

than open-source company managed.

Yeah, there's that.

Yeah, so for those listening,

Ruff is written in Rust and pulls in Flake 8,

and yeah, that's the big selling point,

is that it's much faster than Flake 8 and tools like that.

Can I ask you about inertia?

So I put my hand up, I'm, you know, front of the line for I'm quite slow to change my tooling choices.

You know, I'll be second last off the boat quite happily every time.

And that's fine.

How do you, because basically I'm just not interested in taking on the churn.

You know, if you get into every new tool, you're changing tools three times a year and it's, I just, the time saving is never worth it for me.

That's kind of my natural, my reaction there.

How do you handle that kind of tool change yourself?

How do you, you know, how do you balance between the considerations

of, oh, I've been spending a lot of time looking at tools

and, oh, this is actually a better, this is a step forward?

Yeah, I think I'd be conservative like you with swapping.

But I'm also very happy to go add new tools.

I guess part of what I do is helping companies add tools.

So I've added Flakey to several projects this year.

So I might as well, like, if I'm going to go through it, I'm going to research new plugins or whatever that could help out people.

If you're selling apples, it's helpful to have fresh apples.

Exactly.

So is that, I mean, so I know you do consulting work.

Is there a typical type of project you get brought into?

Is it like everything's on fire?

Is it like everything's slow?

like is there is there kind of a bread and butter or is it you know hey we need someone who really

knows this stuff uh i guess more of the latter um i've helped a few companies this year like just

improve their dx tooling in some way so that might be setting up pre-commit and all the tools for the

first time or it might be like updating things and writing a flakate plugin for logging after i was

auditing the the logging setup for my client silver so so can i ask from a sales perspective

do you have are you able to have any kind of metrics where you can say look you know i had

this kind of um improvement in productivity or you know this company said you know are you able

to gather that kind of data so that you can present that in a sales call it depends on the

problem um one client uh this year asked me to improve their startup time because i'd written

a blog post on how to improve a project startup time the time it takes to import everything before

django actually does run serve or shows you the shell or whatever so i could show very obvious

improvements there like doing this thing saved a second doing this thing save five seconds

if you do this thing you know that's the classic consultant move if you do this thing

Yeah, well, no, you don't want to do it yourself.

I've just had the manicure.

No, fair enough. Good.

Well, I think, though, I mean, even just for anyone to have someone who's trusted just come in and take a peek,

because that is one of the things about code is that often no one outside of your team is seeing anything.

So, right?

Like, I mean, if we all look to each other's code, well, maybe I wouldn't help as much.

But you two would definitely like add a lot of insight, but it's not often done unless

it's like a new team member or you have that external gaze and there's just stuff littered

every, right?

I mean, there's just not always hard stuff that is just unawares because you're busy

doing the thing that you're doing.

I just want, always wonder if there's any way to improve that or, I mean, even something

as simple as like I'm in Boston, there's all these doctors, like surgeons, you know, you

get trained in surgery for forever and then you're just solo for until you retire and a handful have

like brought in like retired surgeons to just like watch them operate and like you know everyone

needs a coach basically um in any field and it's you know in coding you don't always you definitely

don't have that um i don't know a vague thing i've thought about like is there a way to do that i

guess the answer is you hire a knowledgeable consultant periodically to come in and be like

hey like this is what's changed and also here's these obvious things you're doing

that could be improved yeah i think there's definitely a model where there's like a list

of things to go through um if i like look back through all the things i fixed in all the projects

there's a bunch that didn't quite make it into a blog post or a bit nebulous but definitely

something to check when reading code um maybe that's your retainer you should you should have

an ai ai of yourself adam uh you know adam code pilot and just maybe i think as well like the the

dx tooling that you put in place and things like pre-commit and and whatnot especially if you've

got in a team environment where you can't you can't expect a junior developer to come on and

be able to master all these tools whereas if they're they're already set up to run automatically

and that's yeah that's got to have um visible gains for a company that implements that yeah

definitely well we have a little bit of time what what what else can we talk about adam what like

what are you working on what do we or carlton you have well no i want to ask so i've got adam in the

room i want to ask her come on so django 5.0 is just out the door what's on you know your steering

council member what's on the what's on your roadmap now what are your exciting things that

you want to look for us to do over the next you know 5.x series so or if we could wave a magic

one and change one thing what would that be make it easier that makes it easier same thing you're

on the record here boy there's this uh package that uh gordon rickley my previous boss made

that's called django auto prefetch and that changes the prefetch behavior from prefetch uh

Well, when you access a field that

wasn't fetched in your query, like a foreign key,

Django by default fetches a single one.

It changes that to fetch that field for all of the instances

that were in that query set.

It's a clear performance win for nearly every situation.

Nearly all the times that you fetch a query set,

you're going to do something with everything

in that query set.

And last year, I had a discussion about a way

that we could get this in with Simon Charette.

I was about to ask, has any of you

chatted with Simon about this?

Just didn't manage to take a look at it.

It's a big one, because the idea is not just

to add this one behavior, but to add at least one other, which

would be any time you access an unfetched field, just error,

which is necessary in the async case,

because you can't do a database query on attribute access.

But it's also something that several packages have created

in third-party cases.

Django SEAL, Django Xen queries, they're both...

Yeah, those are the two I wanted to talk about at the time.

I just wanted...

Both added this behavior.

So in core, it would be nice to have it

that you could tell the ORM, actually, do this.

And maybe it would be a context manager

or just an option that gets changed we have when we do some some sort of kickstarter to get like

you and simon and marish locked away in a lodge somewhere and you know speaking of that i've had

some people i've had a couple people email you email me about like new projects and you know

kickstarters because that's happened in the past and when i was on the board i was always like no

no the board can do it like let's like we can raise the money and i have to say i've gone full

circle to like, you know what, like the DSF has enough to do and the, you know, if people want it,

maybe a Kickstarter or something like that, isn't the worst way to do it because it's just to have

it within the meat grinder of Django machinery is, it's probably too much. It'd probably get in the

way of things. But at one point I thought, oh, well, the DSF can raise money more easily than

a Kickstarter or something could. And yes, but then you have all the friction of a community,

i guess as opposed to just doing a great new feature what about the issue you've discussed

before about the dsf being a foundation not paying for coding i think you've softened on that sense

that you had the psf pays for coding right well i'm not on the board anymore but yeah i mean i

maybe i'm yeah i mean they have lawyers they looked into it they said it's fine um so you know

if there were any problem, we could just point whomever at PSF and they could deal with it.

Yeah. I don't, I don't think it's a restraint. I don't, I don't think that's the,

I think that was often used as a reason why not to. And, um, at least I'm pretty sure the current

board certainly knows that the PSF is doing it. So. Well, when I was, when I started as a fellow,

it was explicit. It was like, no, we've had legal advice such that, um, you are a community manager.

are um you can you know you can volunteer contribute to django as a volunteer but you're

not your fellow role is not that um now that you know since that that discussion with python has

evolved we talked to we in the board talked to eva who's who's running psf and um you know i've

looked at the history of where that legal advice came from and i i i would trust the python the

psf you know both in terms of who they asked and perhaps the landscape has shifted but psf has

lawyers who focus on tech stuff who said it's fine okay i think that advice was a very conservative

take by someone at the time who wasn't actually in the tech space and then it was treated as gospel

you know we want to be conservative well you don't you don't pay a lawyer for advice and then just

regard the advice that's that's pretty fine oh no we wish we didn't like that answer let's just go

with this one that we made up but this was literally like someone who was you know emailing

me saying like why doesn't jenga do da da da and i was like well you know you could you you could

do something and yeah i think kickstarters or something like that like i mean the question is

should do we need to vote in any way like just send around like hey here's like five ideas or

you know but the problem really is you know how do we get the time of adam and some people

well no no no carry on i wasn't i was putting my finger up yeah it's it's we need we need both i

mean the money to me is easier than the community agreement and the people who can actually do it

finding the time to do it the other thing that's been mentioned is sort of called you know community

sprint like django sprints like you know to keep to get together and have an event a bit like a

django con but without without the conference bit and just do the sprints bit for three three days

or so um and could we arrange that and there's keenness i've seen it's not just paola that i've

seen other you know people who are involved who've sort of said oh is there an idea for this oh yeah

i might you know so if we could organize that and get in a space together that would be an amazing

i mean the sprints are amazing what they do in a handful of hours right like and yeah they don't

have to be attached to the conference so any company anyone at a big company listening to

this who wants to sponsor a django development sprint good yeah this new feature brought to you

by microsoft yeah um well i think unfortunately we're coming up on time adam we're gonna have

links to everything is there anything else you want uh currently you can pre-order the book

right and get a discount is that right it's not is there an official it's not pre-order it's an

early access you get 80 of the book and then you open up some pages and they say to do

i've written up to 90 now i covered the two big bits that were left which are get blame and get

bisect um as more advanced commands i taught them from scratch rather than just being like

you know get blame right well why don't you just turn on this thing

um good yeah so it will be done there's no reason not to go get the book now no there's no reason

you'll save 10 bucks and it'll be out probably in a couple weeks four weeks i don't know i'm

not going to commit to any timeline with a young baby in the house but it's it's coming together

well thank you so much adam it's always a pleasure um we'll have links to everything

people should check out his work

if you're not already using it.

And DjangoChat.com, right?

That's our usual going out.

See you next time.

See you next time.

Thanks very much for having me, Cartman.

Thanks for coming on.