Transcript: Django and Rust Tooling - Lily Foote

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

More on their services later in the show.

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

Gibson, joined as ever by Will Vincent. Hello, Will.

Hi, Carlton.

Hello, Will. Today we've got with us Lily Foote, who's joining us again. Hello, Lily. How are you

doing?

Hello again.

thanks for coming on it's been a while so the big news was that you were elected to the

the steering council yes congratulations along with you carter well yes but you know so we get

to see far too much of each other now all right all right well so let's let's assume people don't

know anything about that like what what does that what does that do and what do you all do now that

you're on it is it one is it i don't even know actually is it once a month how often do you

do meets or is it all email list we've been doing weekly recently um as we got started we were

thinking we should just have a lot of meetings so that we can start working out where we're at

we've just um started to maybe drop down to four every two weeks um but um yeah there's a lot to do

weren't a lot to get started with so so what have we been doing every week because it's not just

it's not just tea and cakes no that's true um yeah we've been um discussing um various things

uh there were a few quick wins we got out of the way first like uh confirming uh marius um

who was a previous fellow as a merger and release it is that it was it was it a merger

was it a merger was it a release oh i don't know i don't even know anymore whichever it was

he can now do that yes um and sorry just for context because once he lost his fellowship

he couldn't do that yeah so the under the depth end rules the um it used to be the case that

everybody who was on the old django core team could hit the merge button on django django and

it was like well hang on that's uh a the old core team you know people who hadn't been active for

10 years where just you know still had commit rights to Django so hang on that's not kind of

how it was and so Dept 10 defined both a merger and a releaser role and I think there's three or

four mergers the fellows and then a couple of other people and then there's I think there's

three releases or maybe even four releases so there's the fellows who do it mostly but then

Marish who's there able to do one if you know you know one was on hold and the other was ill and

marish could step in and get the release out the door and that was something that came up just as

the previous steering council was resigning so um it's not had anything happened with it until we

got going got it and i'll just uh shout out to james bennett because i was on the board when

he was doing a ton of work to kind of make all this happen so um i believe he spearheaded a lot

depth 10 yes a lot of invisible a lot of invisible work he spent on that that i saw a little bit of

it on the board but you know i just just to say like these things you know come at a cost even

though they're largely invisible to the community so it's good to highlight them and yeah i mean

and part of the issue not the issue part of the reality is that django is a big ship and it takes

an awful lot of effort to turn because and rightly so it's got 20 million downloads a month right

it's it's a there's a lot of vested interests in you know various different points and lots of

competing desires and wants and okay that normal it takes an awful lot of effort to get django to

move and depth 10 was crucial in in doing that and setting us up for the for for the next thing

what else we've been up to lady um well several has got uh elected on various things so we've

started discussing some of those i know carlton's big on uh improving the third party package

ecosystem and making that more uh understandable and so on myself i'm i was looking to make

contributor experience better and we've been having a lot of discussions about why is that

not great at the moment what are various things we could try and do to change that

but there's a lot of stakeholders and it's a very thorny problem um i mean looking over at

the linux kernel they're dealing with similar problems of um there's the rust in linux project

who are wanting to make big changes and then there's the maintainers who are wanting to make

sure that they're not left supporting stuff without um enough time and energy and so on it's

and we're facing similar problems it's it's it's a tale of as old as time i think tale as old as

time um so can is there any sort of headline sort of things that you that stand out to you

so you know it's been a couple of months we've been meeting every week we've got we talked with

the fellows we talked to you know all numbers of people what sort of things step stand out to you

it's like okay you know this is doable this isn't this this will take longer this is quicker yeah

um i'm not sure there's any really really quick wins um with the contributor experience

thing one thing that i think we've agreed will be helpful is to try and

uh get new feature ideas and discussion away from the attention of the fellows because it's a lot of

energy that it takes from them and try and replace that with a process that is more community driven

and um once we've as a community decided that actually yes we do want to pursue this idea

then it can get put into track and worked on and get the review and so on

from the fellows how exactly we manage that is still being discussed we've long

used the forum as a hey you've got a new feature idea you should discuss it here

first one of the problems we have with that is that discussions tend to fade away and no one

realizes that they're actually ready to make an action on sometimes there's disagreement and it

filters out with no one agreeing or sometimes people are like yeah that seems a good idea but

no one takes the next step of moving it on as it were um so we're thinking about ways we can

maybe uh formalize uh which ideas are worth thinking about more and having a way of tracking

them better we don't need to turn this into a steering council meeting but it's helpful helpful

helpful for the rest of us to have a sense of what all is happening i think i think this i so i mean

the conclusion to draw at least from outside is that there's lots of activity and there's lots of

stuff going on it's even even if not instant um leaves visible but we've we've we have got a

project a good project board that people can go and have a look at and and all the rest we should

link that in the show notes but that just sort of shows what we're thinking about now actively and

what we know exists for you know later on when we've got a bit more capacity what's what is that

under is that under the django it's under the django org and then i think it's a mystery github

projects are an utter mystery all right i'll put it i'll find it and put it in there yeah no but

i believe it's a project an organizational level project called steering council something and

then there's also another repo with our meeting notes where we're putting on every week there's

You can go and see the meeting notes and what's been discussed and all the rest.

It's github.com and then if you click the projects tab, you'll find it.

Okay.

I, we, me and Jeff should link to that in the newsletter as well, I think.

So we'll do that.

So one thing we wanted to do was be more visible, right?

We wanted to show that.

So, you know, if we're going in the newsletter, it would be amazing.

Well, I mean, you know, yeah, now that I know about it, we'll put it in there.

But, you know, I remember, you know, being on the board, the secretary would take all

these notes and we had all these extra work to have some things were private and some

things were public, but it was just, you know, in this dark, dusty corner of the Janker Project

site.

So it's sort of, anyway, so it's doing the work and then it's like telling people about

the work.

Speaking of which, we should, we make sure that on the newsletter, we're linking to the

board notes because we were for a while but as well we could put those in the show notes because

they the board notes now go up on a you know it's a whole django app in the in the django project.com

website with a model and a list view and all sorts yeah jeff and i need you know because we we have

the django updates which various people um do which is great because it means it's in there

every time and it's a quick way to see oh yeah there's double digit you know things you know

added um every week so as much as it i think we talk about you know being stuck and slow like

there are all the all these things happening so just on that little side thing lily i just

do you have any thoughts on how we might or are we communicating well enough do we need to improve

do we have any ideas and maybe the answer no i don't have any ideas but like can i recommend

the blog the blog was good you guys did a quick blog post like that's super easy sorry to jump in

that's super easy for like the newsletter to link to for people to post on social

to me that seems like the easiest way to like link to stuff for example i think i am worried

that we're even with the communication we are doing where it's probably not enough probably

not visible enough we do have uh our steering council uh minutes posted on the forum i think

but

I

I think until we start announcing

that we're doing something

rather than just discussing what we might do

it's difficult

to be more

open about

what we're doing

talking about it on the podcast

like we were just now is one way

but

um yeah i there's a lot we're talking about and not loads of it i think is filtering out

at the moment but hopefully that will change yeah there are no quick fixes i guess is a thing

so talking talking of quick fixes this wasn't a quick fix at all you were involved in uh this

year's google summer of code project oh yes so tell us all about this because it's headline

feature of Django 5.2 coming up? Yeah. Well, so composite primary keys, the oldest at the

time open ticket in Django. I started to look at it a bit myself, but life circumstances

and so on meant I wasn't making loads of progress. And then Ben comes along, says people

wants to do it for google server of code no one else has been proposing this but he has a proposal

it seems good uh so we say yeah let's give it a go and he's just absolutely blasted through it

and it's a success right it's in yeah i mean there's still more to do there's um foreign

key support and generic foreign key support specifically but an awful lot of the work has

been done and it's as far as i can tell really solid well that that's a big thing i was just

talking to someone the other day who was who didn't know that was coming who was having to do

that their own you know their own cobbled together way for performance reasons so they were super

excited i think it's also there's a pull request which may or may not have been merged out haven't

tracked closely but that uses comprehensive primary keys somewhere in the django website

fancy would that be to do with track in some way so because yeah i was definitely talking

to baptiste at the last django con about track because he you know busy maintaining that and

he was like well i would write rewrite it as a django app but composite primary keys it's like

well you know you've got no excuse baptiste yeah i don't 100% remember which area it was but they

had something that was basically a composite primary key and they the pr was to make it

actually a composite primary key my um i don't you'll tell me this if this my sort of understanding

is that it's going to be most useful for people integrating django with a legacy database in the

first pass right so you've got an existing schema that uses composite primary keys and then you'll

be able to attach a django model to it much more easily yeah i think that's a very solid use case

for it there's also potential use cases in multi-tenancy um oh right i think the

motivating use case for ben who's working on it um but yeah there's various use cases for it and

especially once foreign key supports in it should be very solid yeah and it's going to be another

one of those exciting periods where the patterns the usage patterns immerse merge over the next

couple of releases right yeah and how was mentoring like you just sat back and yeah

yeah we had i think we had weekly meetings and i reviewed the code as it came in and

there wasn't much more to it than that he had a very clear idea of what he was

trying to do so it was just about okay uh helping him understand the code base

and um making suggestions on how to do things a bit more jango-y but it was actually quite hands

off okay super and now you have to remind us i know you've you've with jango not you've been

a navigator and i believe you i was a navigator on the pilot session jango not space and then

life and google summer of code got in the way and i haven't done it again i would like to but

time constraints yeah yeah yeah well but just the fact that it's you know it's django knots

who are often doing the update the django the updates on django itself and the as i think we

probably discussed a year ago the whole point is it shouldn't be the same people dipped into every

time it's like you know when you have the bandwidth contribute and um so it's great that there's an

organization and structure around it to facilitate that so it's not the case that yeah i think it's

one of the biggest wins of the past few years, more than any of the technical contributions,

even though Composite Primer Keys is amazing. I think Jackknock Space is even better still.

I would agree. So there's a couple of things we want to talk about, but I feel like coming

from these highs of Steering Council, Google Summer of Code, so you're willing to share with

us that at the moment you're in between jobs because you were made redundant of all people

are you willing to expand upon that because so many people have trouble getting a job

or keeping a job and then for someone like you to lose their job yeah is um i think it's helpful

for people to hear about that because it seems quite shocking but it happens yeah so um i started

at um back in november and i was getting settled in working on understanding the code base

doing a bit of support for other people in the team that sort of thing and at the

and then in january as i was expecting to pass probation which my manager had told me he was

expecting me to do. I discovered that the company had overhired and were having to do a redundancy

round. And I believe a lot of my team went with that as well as just me. But yeah, job hunting

again it's not the not the most fun experience well but it's you know companies there's a lot

of cost to companies doing that right obviously they're not trying to but just just from a

for them to hire a team and let go of a team clearly they didn't want that obviously you

didn't want that indeed but um it happens so well and then um so where are you at now right

Cause I know when we spoke to you last, you, you worked on, um, colo for quite a while

and you're doing a lot of rust.

Are you, how much, what would you say the split is between rust versus Python Django

these days for you or in terms of your, um, you know, dive in right now?

Well, given I'm unemployed, it's all side projects at the moment.

Yeah.

So, um, do you have a preference?

I guess I would say, right.

Because you know, we often, we often lose people to rust and they don't come back.

i mean at the moment i'm trying to do both it's um rust is exciting i love a lot of the power it

gives me and the performance but i also really love janga for its flexibility and um just ability

to get something working that is very easy to get to production quality um it's battle tested

and stuff like that well let me let me ask you because so i'm a little late to the party but i've

and i'll probably attach it to this i hopefully i have a tutorial finally on uv and django um

so uv is written in rust it's the package manager it's taking over the world you must have some

thoughts on on that and how they did that right because they sort of they did it from scratch

as opposed to cobbling together other existing pieces the way most of the other tools out there

had had done yeah it wants to be it wants to be the cargo for python yes exactly double aspect yeah

yeah the rest the rest package manager it's very impressive uh there was a keynote at a rust

conference uh by uh uh the founder of astral charlie marsh yes that's the name um about uh

a lot of the stuff that they were doing with uv and from a rust perspective and

that's great watch i highly recommend it um i've not actually used uv much myself

um but uh yeah it seems really solid and it's taking over a lot of the python mindshare at

the moment i should go watch that one because i was just i think i'll link to it he gave he's

given a number of talks he's quite good at it there was one too i think it was a jane street

which is like a quantitative trader. So it was a little more hand wavy, but he was, and this was,

I think four months ago, but he was saying how, you know, it launched in February. And so four

months ago is what, like November, it was already 10% of all PyPI downloads were using UV. And,

you know, it is, it almost seems too good to be true, right? That it, on the one hand has like a

single, you know, lock file for everything. It also can do your Python and it's not, and it's

fast but it's so fast that you can do things like move things out of ci into pre-commit like so fast

that it can change the way we work so that in some ways is the most interesting thing to me because

that was one example but i'm sure there's others if you just don't even have to think about

any of this stuff you know that sounds great and i sorry that's kind of what i'm super excited about

Yeah, I think as long as you are willing to learn the new workflows, it's probably a really solid choice these days.

My problem is that I have my own workflows that I really like and I haven't just felt like investing the time to adapt to UV.

Well, sure. Right.

And I think it, you know, to the, you mentioned the sort of battle-testedness of Django, you know, it's, I believe it's VC-funded.

They still aren't at a 1.0 commercial release.

Everything looks positive so far, but that is an additional risk, right?

Yes.

Who knows?

At some point, they're going to have to do something, right?

They have ROUGH.

They have UV.

Yes.

Monetizing in the DevTools space is tricky.

I mean, Docker managed it, I guess, right?

so i'm sure that's an obvious uh but you know it's yeah it's also interesting you know docker

is in on teams right if you all just use uv and it's all in a toml file like does that remove the

need for docker in some situations like i'm i'm still a little bit ignorant on it but it seems

like it would in some cases maybe i tend to avoid docker unless i have to use it for work reasons

anyway so like docker for local development it's just like sticking needles in your eyes for no

reason like yeah yeah carlton's carlton's carlton's yeah i i've i i hopped on all you can bootstrap my

local environment then you know well yeah that's an interesting proposition well in the whole python

thing like the the pyenv um you know you don't need pyenv if you can just put it in uv uh yes

That's such a huge thing just for beginners, right? Because, gosh, it's a minefield. I mean, and a shout out to my employer, PyCharm has UV support now, which is cool. Now, there's a question of levels of support. So we're going to have even more integration.

But, yeah, it's pretty wild that something that's a dev tool that's foundational can be so popular so fast.

Because this is not a space, like, there's an XKCD on it that I saw Charlie put in one of his talks.

Like, this doesn't usually happen around standards.

I think there's been a lot of frustration with the legacy tools in this space, which is one reason.

and it's achieved such good adoption,

they've got a lot of the UX right with it,

as far as I can tell, especially with the performance.

But as well, the single tool, right?

It's the single tool that does it, that does it right.

it shows how, you know, a decent amount of money goes an awful long way, right?

So they've managed to fund a team and actually put them on it full time.

And all of a sudden, all these problems that were insoluble for a decade or more

are resolved in the space of a year.

Money is the fixer for of all evils.

Well, and it's the combination of the rest bit.

But then just even if they just rewrote it all in Python from scratch with the money,

there would be some improvements you know not maybe not as much but there would still be

no one yeah no one had the desire or the time to to do all that that's kind of why i'm curious i

want to watch that rust talk because i've read a little bit about it but i want to understand a

little bit more what actually they all did from scratch yeah i think there's a lot of

clever people who've worked on it and therefore a lot of clever ideas in

how to really optimize things.

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.

And Carlton, so are you a UVer or whatever the phrase is?

No, I'm not. I'm not a UVer.

You know me.

Well, that's why you sounded like you were on board with it.

No, I'm interested. I'm looking at it.

i'm investigating it i've i'm not using it in battle like i i mate it takes an awful long time

to get me to change tooling like an awful long time well all of us again this speaks to i mean

i haven't done anything real with it other than toy projects because it's kind of like well if

i'm not facing speed problems and my team isn't crazy frustrated like yeah no why would i but

that it doesn't all of the problems it solves i think brilliant none of them are problems that i

have um and so i'm in i'm happy to watch it i'm i'm probably in the position where if somebody

said should i use uv i'd be like probably it doesn't the fact that i'm not using it doesn't

mean you shouldn't um i'm old man herding goats on the mountain that's me and you don't need to

copy what i'm doing at all i'm slightly skeptical about the vc funding position i have to admit um

i'm slightly more concerned about that than other people you know other people are happy to say oh

let's not worry about it a bit of money is all good but money is all good that's super i'm

personally interested in making sure that that what that i know what the state of play in the

community tools are so that you know if it all does go horribly wrong i don't feel like oh god

we're now trapped in a you know vc hellhole now that's just you know that's very unlikely to ever

come to pass and it's you know the astral team are all great and they have no intentions to all that

but you know just as a matter of you know diversity within the community i'm happy to hang

out with my crusty tooling for a little while longer i i feel very similar to carlton on this

except i wrote my own tooling right yeah well you would you would

well for a long time i wouldn't but recently i i have yeah well i'm quite sure i'll be doing a

pycon us demo of uv with pycharm amongst other demos so i'm uh as much as i would love to hang

out in a cave and herd goats i'm uh forced to i think i absolutely have no problem with other

people doing but i've been using the same salute i've been using virtual and wrapper for 15 years

plus and i have no intention of changing any time but i think it's it's it's this interesting to me

some of these tools or things like this barbell shape we're on the one hand like power users or

speed matters boom like yeah they'll flip over and then and then the beginner thing right and

this is the like three of us are a little removed from being pure beginners but god like you know

you tell someone oh yeah just install python okay like yeah exactly exactly right like there's so

many tools so many ways to mess it up and then if you can so i'm in some ways i'm almost most

you know just from the teaching angle i'm most excited by that because i have seen how

ridiculous that is and um yeah i think that's for me that's the most exciting thing as well i think

an easy reliable it works here's how you bootstrap your python environment which isn't going to

confuse beginners i think that for me is the is the speed is a bit like speech meat you know like

and it's the same thing that everyone else is on everyone's on exactly the same one

you know that's yeah yeah i mean and even i think this is a little bit maybe hidden to some to some

of us but like just installing python has really improved in the last five years i mean python.org

installer is great microsoft with the windows support i mean you know even five years ago it

was like i had you know every time i got a new computer i was like oh this is gonna blow some

time and now it's i don't want to say trivial but if you know the steps it's not so bad so i have i

have robbed one bit from uv is that i've started using the standalone builds on servers because i

was using pyenv and it just i feel no need to compile python i would really really love if

python.org would ship recompiled um i think standalone stuff is amazing um and that was

actually created before

Astral, and Astral have adopted

it since.

They're using it.

Release the maintenance burden.

I'm not actually using downlit UV

to fetch the standalone builds.

There's a sort of, you know, nominal

flag in the ground for no reason

to any point.

Well, if I can

switch...

The templates, Jenga Rusty templates,

right? Yeah, all your side projects

built in rust we're rewriting django in rust yeah tell us about this um but i mean after i left

colo i was uh looking for some way to continue using rust and

templating is one of the more performance sensitive areas of django i think

yeah absolutely from a cpu side of things rather than an ioth so i thought but also

just to give context here any sorry to butt in but any request any request it's going to go

what's where's your time go i went database templates by one and two so anyway carry on

yeah so i was thinking well i love django i'm really enjoying rust what's the best way to put

those together and templates was the answer I came up with so since autumn

last year I've been trying to build a parallel implementation of Django's

templating language using Rust and I'm aiming for 100% compatibility of

rendering so it can really just drop into an existing Django code base and get all the

potential benefits of having been rewritten in Rust. I'm not at a stage to do any benchmarking

so I don't know if I've succeeded yet on the performance side of things but once it's complete

um for a given version of django i can then start looking into benchmarking and

performance improvements and all that sort of stuff okay so that sounds really really really

exciting can i ask you a question if i've got a custom template tag yes how would that work

because that would be written in python yes this is an unsolved problem right now

it's it's been on my radar as the thing that i am going to need to solve at some point but i

haven't got around to it yet okay okay fair enough it's good to strike that away though

i have some ideas but i haven't looked deeply and really grappled with that one yet i'm just

try and get the core stuff working uh the other thing i'm uh really trying to do with it is give

better error messages than django gives because if you get an error in django templates you get

this horrible trace back of django templates internals and it's not really very easy to

understand what's gone wrong often now we could fix that though couldn't we aren't isn't there a

way of marking frames as to be excluded from tracebacks somehow possibly i was reading a

rich that i was reading the rich docs yesterday because i was doing it and they've got a traceback

thing where you can say skip these frames skip that frames and i was like ah we could do with

in django because who wants 30 frames of template internals like what's the uh yeah instrumented

render 48 times as you go down the node list yeah i definitely encourage any um anyone looking for a

fun issue to try and tackle that we should create a ticket in tracks so that someone could do that

because i think that that'd be a useful thing to have and it's probably not too difficult

maybe i love it i love it i love it can i ask your take on um because i love the django template

language and i one thing i love in particular is just not defining a particular um variable

deliberately not defining a particular variable and then so having the whole block just vanish

away because you know the if defaults to empty and it it knows what to do and it doesn't raise an

error but lots of people don't like that they're like no no no i i really want i really want this

to be much more strict with me do you think there's any way we can sort of be have a template

say look this is what i'm after and you could lint it maybe the the context you passed actually did

have the variables that the template was looking for or something i don't know what's your thought

in that space i think there's some room for exploration there um it would be nice if django

could um be more strict for the people who want it to be more strict the trouble with that is i

don't think it can be a global setting like most of django's template settings are because existing

stuff like the admin and third party stuff might very much rely on that feature so i think what

would be necessary is a way to limit it to templates that have been written by the developers

of the project and then they can opt into being strict on their own templates but fall back to

not strict when interacting with these upstream templates the idea an idea come half comes like

this is just me making stuff up to go along now but idea half comes to mind of like having a

template tag that sort of defines what the expected context is and then takes the context and sort of

lints whether those are true or not but we'll have to we'll have to brainstorm this at jango

Yeah, there's yeah, there's a lot of I think there's a lot of stuff in templating that actually could be

explored and improved and it hasn't really had loads of attention for a while

with the popularity of apis over templating but i think especially with hdmx templating is

coming back into vogue in django so yeah i think it's absolutely happened

but so have you seen all these exciting component libraries are django components

django bird dj angles like these various slippers i've i've seen some of that from a distance i've

not dug deep you haven't got one which is waving the flag no i mean um

well i haven't really worked on a django project for a while

um because with colo i was writing tooling for programmers not writing a website really

um so i'm really kind of rusty on some of this stuff but also you're more of a back-end you're

more of an orm expert right i mean yeah uh anything back end has always drawn my interest

front end has always been complicated and scary well can i ask what do you feel the pull at all to

you know given your skills uh are you still happy in web land or do you feel that the data science

pull at all um i don't know about data science but well i guess everything else right that's

the problem with data science is it encompasses just like everything else with programming

languages that isn't web certainly dev tools is interesting to me um rust is known primarily as

a systems language so getting into doing more systems type stuff could be really interesting

I know that the embedded world is really cool, but I've done basically nothing to know how to work with that.

But there's a lot of areas of programming that I would actually quite like to explore more.

But there's only so much time you have.

It's a question of how much do you lean into your existing skill set and how much do you try and do something new?

And, yeah, I'm really trying to find that balance, both in my open source life, like building Jack O'Rossi templates, and in my work life, whatever turns out to be next for me.

Well, one more question, then I'm out of questions for both of you, actually.

So in the Rust world, which I know, Carlton, you've spent some time there as well.

So taking Cargo, taking Package Manager, and then applying it to Python,

are there any other obvious things that Rust does that Python, with a bit of money and brains,

could or should adopt, do you think?

I haven't thought of anything obvious yet.

Carlton, any ideas while I continue to think?

The thing I'd like to see more, I was going to ask you a little bit about this,

is that if we could improve the story around the Rust to Python integration,

so there's Maturin, it makes it very easy to package up,

but it's still a bit, you know, if I'm just,

if I'm quote-unquote just a Python developer,

and then I see this, oh, I could go and build something,

this Py03 thing, what's going on?

Ah, it's still, you know, you still want to dedicate two, three days

to sit down and plow through it, and oh, yeah,

now I've got my hello world from Rust.

That was quite a lot of...

Go on.

I think the Python Rust interoperability story

is actually really solid.

It is, but still...

I mean, if you compare it to what you had to do

to get an extension module before this came along,

C, C+, Cython, it's all way more painful,

at least my impression from the outside.

than i ever found the experience with rust i think i think the maturin uh developer and

team have done an amazing job of just taking advantage of the python packaging back-end

evolution over the past uh years that and built something really solid and

And PyO3 is a really solid piece of technology, too.

I've actually joined the maintenance team of that.

Oh, have you?

There you are.

There you are, folks.

If you're looking for a Django ORM expert that also does Rust on the maintenance team of the Rust Python integration framework.

I think you need to think bigger.

You need to go raise some VC funds and do something.

I mean, you have the background, right?

You have the perfect background of Python, Rust, DevTools.

I don't know what specifically that thing is,

but, you know, that's all you need to do is say,

yeah, I can do it, and, you know, Astral's doing it.

So, you know, VCs are trying to spend the money that they have.

Anyways.

I wonder if there's one thing we could pick up

from the Rust ecosystem, which is additions.

So particularly in Django,

we have very strong backwards compatibility constraints,

correctly so because we've got those 20 million downloads a month that we have to keep thinking

about but additions in rust allow you know you to step forward and say no we're going to drop

compatibility here and we're going to step forward and now you have to be using this addition if you

want to be using this um well it's a bit more nuanced than that with rust um because they

have extremely strong backwards

compatibility

I think

you can

use a new edition

in your own code but depend on code

that's written in an older edition

and

they've defined these editions

in such a way that

the compatibility

between those is

still there

they're sort of forward compatible

so you can opt into

the better behavior but in a way that still integrates well with what's gone before which

does mean that you can't make some backwards incompatible changes that you would like to

because you can't keep that cross edition compatibility but

i would like a

i i think django has some rough edges and bad defaults and stuff like that

that there's a quite a bit of resistance to changing and improving

i would like us to find a better way to handle that and something like additions like something

I mean, maybe, I mean, what's the difference between an edition and an LTS?

Maybe we could do something where we improve defaults every LTS cycle or something.

Okay, well, we'll have to see how that rolls out.

One thing I wanted to ask you is about, we've talked about UV and we've talked about Rust,

And one thing that Rust does very well is CLIs.

And, you know, we've talked about the dev, the DX developer experience of UV and how they've nailed it.

And there's some, you know, wouldn't it be nice if we could, you know, improve the DX of Django somehow?

Yeah, well, there are some really nice libraries for command line stuff in Python as well.

I really like Qlik.

There's a terminal user interface.

Is it textual in Python?

I can never remember.

Yeah, textual.

Yeah.

And I suspect there's a third-party library out there somewhere

that integrates those with Django's management commands.

Oh, there is.

If there isn't, there should be.

Yeah, there is one as well.

And there was a release of this typer as well,

which sits around Qlik and makes it type-inted.

Yeah.

And there was a release of Django Typer as well, quite recently.

Yeah, so, yeah, I think it might be nice

to start depending on Qlik in Django

so that we don't have to deal with ArgPass

because ArgPass is kind of crufty.

It's not tight enough for you, you know?

You like it?

I mean, it works, but it's verbose.

I think it's been demonstrated that the third-party ecosystem has done better,

and it would be nice if Django opted into that, I think.

I've got one sort of half idea.

It's that we should build all these things just around Django

rather than necessarily trying to force the Play-Doh into the shape

it doesn't want to go in.

Sure.

then the problem becomes discoverability rather than backwards compatibility trade-offs yeah

anyway we'll start well we're covered a bit of time is there any are there any things that

you wanted to mention or we should have asked you about while you have a microphone

literally and figuratively nope nothing's coming out of mind okay so i've got to ask you run the

steering council you've got all the power you've got a magic wand to wave what's the thing you're

going to fix in jane well it can be community it doesn't have to be framework yes i mean i ran for

election on this it's got to be trying to make the contributor experience work better for everyone

involved than it has been before okay fair enough well we've yeah yeah we've we've we've covered all

the things so this episode will come out in three weeks so if your linkedin profile says you're

still looking for work people should reach out to you um but again i think it's it's just i've just

got to say one more time nearly contributed to the orm rust being on the pi 03 maintenance team

And, you know, there isn't much more you could ask for if you're looking for someone, you

know, with some chops.

Yeah, but I appreciate you being willing to talk about publicly because this is a thing

that happens and it's not just newcomers who have this issue.

And so thank you for agreeing to that.

Hey, my pleasure.

So we're going to have links to a whole lot of stuff, including Lily's packages and check

them all out.

And we are DjangoChat.com.

We'll see everyone next episode.

Bye-bye.

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.