Our two Django Fellows join us to discuss new features in the Django 5.1 release, major improvements to accessibility, future updates in Django 5.2 and 6.0, and more.
Carlton Gibson 0:00
This episode of Django chat is sponsored by talk Python and their new HGM X courses the links in the show notes, and we'll tell you more about them later.
Hi. Welcome to another episode of Django chat, fortnightly podcast on the Django web promo from Carlton Gibson joined us over by Will Vincent, hello Will.
Will Vincent 0:19
Hi, Carlton
Carlton Gibson 0:20
Hello, Will. And today we've got with us two special guests, two Django fellows, Natalia Bedard and Sarah Boyce. Hello. Hello, fellows. How are you? Thank you for joining us.
Natalia Bidart 0:31
Hello.
Sarah Boyce 0:31
Hello. Yeah, very well, thank you.
Carlton Gibson 0:35
Yeah, right, exactly. That's more, that's That's more like it, right? No way. Assignments, please come on. I don't know will that's it. I've done the intro. You have to ask a question now. Okay,
Will Vincent 0:44
well, so this is our fall season, and what better than to start with our fellows? Since 5.1 just came out, you're already working on 5.2 and I know thinking about 6.0 so maybe I'll start with a question. 5.1 is there one feature that each of you was most excited to ship? Because it's always a race at the end to see if something gets in.
Natalia Bidart 1:04
Okay, so, well, I am Natalia. I was the release manager of 5.1 so I don't remember from the top of my head what we were running against, because it feel like we were running with everything. There is always, you know, all the all these branches that we want to push forward to the final line. Because, I mean, at least to me, it's very important to have the contributors feel like what they do is eventually seen and used by other people, so that may not having that merge into into the angle. But from the things that were released, I love the query string, template tag, the new template tag that was merged, I have been implemented by hand for many years, so I haven't started switching my projects to using it. And then there is also some work that Sarah picked up, which is the postgres connection pool. So maybe Sarah, you can tell us a little bit more. How was that like?
Sarah Boyce 2:14
Yes, I mean, I would say it's more florian's work that I helped near the end with but yes, now that was a feature we had been worked on for some time, and we managed to get that into 5.1 so yeah, very exciting.
Carlton Gibson 2:36
So could I ask a question on that? Because I've, I'm quite excited about that. I'm going, but I haven't really back or tested it to know, can I? Can I, in theory, can I get rid of PG bouncer now, because I've got PG bouncer everywhere. And maybe one less thing, maybe, maybe,
Sarah Boyce 2:53
yeah, I mean, definitely try and, yeah, it's quite nice to see the 5.1 go out, because it just means that we change the flavor of our release blockers. I would like to learn what's what's working and what's not working. So the more that people use it now, the more we will know how well it's working for people soon.
Carlton Gibson 3:19
Okay, and we'll find out over the next two or three releases. Oh, do you know what this needs fixing that,
Sarah Boyce 3:26
yeah,
Natalia Bidart 3:27
And also, sorry, I happen to know that Jeff might be trying connection pool pool as well. So you might want to reach out to him, okay, and encourage each other. Well, sort of connection
Carlton Gibson 3:39
pool support group. Yeah, yes, yeah, okay, that's fine. I was in a get context data today, and I was looking at some logic, and I was like, What's this doing? And it was building a query string. So in my view, and I too, am quite excited about the query string template tag, because all of that can just be, like, moved over to the template and one line of Django versus a horrible mess
Natalia Bidart 4:03
Tom. Tom did a great job there, and it's super useful. And actually for 502, we are, well, a contributor is extending a little bit to make it a little bit more flexible, and being able to pass a name parameters to it in order to do things a little bit more fancier. And then, going back to 5.1 we also have, well, the logging required middleware, which is something that you can enable in order to have by default, logging required on every view. With that, we shipped new the corrector to not require login on a given view. So you can have a few views, particularly for logging and not to require authentication. And then there is this huge push regarding accessibility that has been happening from before 5.1 but you can see the most noticeable Well, I think. Like the most noticeable consequences of that push in 5.1 and there will be more in 5.2 about assorted fixes regarding accessibility in the admin in particular, but also some widget level which will help your application, even though outside the admin and to do the right thing in most cases, for when defining the different htm attributes for accessibility. And I would like to call out for that the accessibility team, I think that this wouldn't be happening if it weren't for them. They have been working a lot since more than three five years now, and they have been not only doing work, but also inviting more people to join the team and training them and helping them becoming accessibility experts as the original group. And we are seeing more and more efforts being proposed and fixes being proposed by the community, but not only by the initial team, but also from new contributors. And I think that's great, and I think that's going to help the accessibility part of the angle a lot.
Carlton Gibson 6:12
You said a key word there. You said training, because for years, I've sort of known accessibility is important. I've known the basics. You know, use your headers in the right structure, use labels and forms. But there's a step beyond that where I'm a bit like, Whoa, big chasm of knowledge I don't have. And so how are we, or how are the accessibility team, pushing that forward? Because forms
Will Vincent 6:34
just do it for you. Carlton, forms handle it.
Carlton Gibson 6:38
Whoa,
Will Vincent 6:39
there's that, yeah,
Carlton Gibson 6:40
there's that, yeah
Natalia Bidart 6:41
I think it's super important these kind of specialized groups. I will love to have a similar one for the ORM. In fact, Sarah and I have been starting some conversations around that. I think that it's at least I'm trying to embrace the notion that there is, there are a lot of things that I do not know and that I need training on in asking for that it's okay. It's not like I should know, and I should try to hide in secret and learn by myself. It's okay to ask and it's okay to share. And that learning, I think, is much, much richer than doing this on your own.
Sarah Boyce 7:23
I also think Thibauld with in collaboration with the accessibility team, he's been working on some contributor guidelines that he's wanting to add into Django, which will hopefully at least give people an appreciation of the different elements involved in having an accessible web page, the different kind of tools that people are using to when they Experience the webs, different screen readers that are popular and so forth. And I know with the part of the reason they wanted to increase the team is ideally, they also wanted users and testers of of this software so that they can, you know, with real life experience say whether it's working for them or not. So, yeah, no, I think, and in the process, I think we all are learning when, when we're reviewing these pull requests, and I've had the joy and the pain of a screen reader experience. And it's, yeah, it's really interesting, and you learn bits along the way. Yeah,
Carlton Gibson 8:50
I think that having that kind of guide is amazing. I mean, why do I even talk about one thing? It's a massive learning opportunity, right? And just as I know when you start, and you go to the Django docs, and there's all this, how to write unit tests and how to run the test suite. And you can take all of that stuff, and you can apply it to third party packages, and you can apply it in your work, your work. And you could do, oh, look, I know all about testing. Why? Because I help contribute to Django. Well, the same here, right? You can learn the accessibility tools, apply them on Django, take them to your third party packages. Take them to you what that's that's a lovely reward as individual contributors, we can get from doing, you know, learning these new skills.
Will Vincent 9:28
So I know you alternate being release managers. So Sarah, you're up for five two or sorry, Carlton, do you have a question before I ask?
Carlton Gibson 9:38
Yes, just before you go for this five two. So, Natalia, you said you were the 5.1 release you still,
Natalia Bidart 9:48
yes, I know, I know, I know. I've also, well, I was also the 5.0 release manager, and I just finished that on August 7. And then
Will Vincent 9:58
once you're done being a. Fellow, then you have to help the new fellows be release managers, right? Carlton, is that how it goes? You never really, no, I
Carlton Gibson 10:05
know. You go off on hold. Then you never could. You never put a word, yeah, there's a sort of dusty patch where there
Will Vincent 10:14
was some, let me, Sarah, before you go in. So, Natalia, how? How different was it the second time versus the first time, I know we we had interviewed you, and especially the first time, right? It's like, Oh, my God, it all relies on me. Is the feeling that I hear fellows say,
Natalia Bidart 10:30
well, the second time was so the first time, I had no idea what I was doing. The second time, I had like, 20% of idea of what was doing. And so I guess I felt less panic, and I sort of knew what was coming. So I think that made a huge difference for me in terms of being able to prepare a little bit more for some things. Also, I tried to one of the things that were more the word that I'm thinking is invasive, but that not necessarily applies for the final release. You need to fetch all the translations from trans effects into the bundle that you're releasing. And that process, it's extremely cumbersome and tiresome, and it's very time consuming as well. So between 5.0 and 5.1 I try to propose a small improvement towards that, in order to choose a little bit the trans effects API for in order to fetch the translation a little bit more smartly in that using some days in order to fetch what is really needed. So that helped considerably. And so yeah, overall, it was a slightly smoother process.
Will Vincent 11:52
Well the first one or two releases are in some ways the best to change things, because you're still coming at it with this new newness, and then I imagine after a while, you sort of just accept certain things. But when you're new, you're like, well, that doesn't make sense. Let me, let me fix that right? Just like when you join a code base for the first time, I feel like six to 18 months is kind of your your sweet spot, where you fix stuff, and then after 18 months, or the technical debt, just like wears you down. You embrace, in my experience, yes, you embrace it.
Natalia Bidart 12:21
Yes, yes, absolutely agree. Yes. Sorry, so
Will Vincent 12:25
Sarah, what is the, what is the, what is the, what is the training process like for being a future release manager?
Sarah Boyce 12:33
Oh, gosh. So Natalia is very helpful. I have had some unsuccessful and some slightly more successful monthly releases, so at least some. Okay, so for those who don't know, we generally will have a release every month. These are the the final, the 5.1 point two, for example, those will happen monthly, pretty much, partly, they don't necessarily happen. They are they happen if there are release blockers that we backported fixes for or there were security fixes that we did a release for. But in my experience, it happens every month. In theory, it can skip. So we take it roughly in turns to do this. In theory. So I've had at least an experience of releasing a new version of Django with the feature release itself. I've seen some things that have been happening in the background. But until you're doing it, I wouldn't say it's, yeah, it will it will come. There are docs, and there's also current fellows and former fellows and people to support. But yeah, we'll see how it goes. Well,
Will Vincent 14:20
the timeline, I think, because it doesn't, it's April, right? It's every eight months or so. But that feels like a long way off, but really, sort of the next couple months is when what's going to be in it is really decided. I wonder if either of you could speak to what is the internal timeline for for these releases, right? Because on the outside, we just see every eight months it appears. But I know that's not how it works. So
Sarah Boyce 14:42
I think the Alpha freeze deadline. I think that's January 15, so that will be then that there is, like another month or so where book fixes can still be back put so at that point. We make the cut. We then the branch for 5.2 exists right now. We just have main and then we have stable slash, 5.1 point x, and then so forth. So on january 15, I will create a new branch called stable slash, 5.2 point x, and then there will be no more new features and no more API changes in that. So there will be no new deprecations. Nothing will be removed. It's at this point is pretty much stable in that you should be able to try it out and try everything out. At that point, we will there is then a bug fix, freeze, a beta release that we will do. So at that point, we will stop back porting some of the bug fixes that are going into main which are kind of unrelated to 5.2 but then after that point, we still backport stuff in but they will only be related to the new stuff, so anything that was changed or added in the 5.2 that has an issue that's going to continue to Be backported. And then even after the final we still back put those into the monthlies. So I'm not sure if that makes sense, but roughly january 15, no more new stuff, and then just fixes going forward. I
Will Vincent 16:33
mean, that aligns with what I've heard, but I've talked to Carlton and Tim and stuff, so hopefully for for listeners, that gives a little more sense of the magic.
Carlton Gibson 16:44
Think it's worth saying about the Stability Policy at this point, right? So what? What is it that gets back, ported to a supportive version of Django? Well, say it's an old one, like 4.2 or 5.0 will be or 5.0 now, what gets back? There's just a data loss bug or a crash, something really serious, and nothing else, because you can't be, you can't be back porting changes to something which is deployed on loads of loads of installations that are out there running in the wild, because you're going to break some of those installations and so they don't get backported. What gets backport is just for that mainstream port that first eight months after the release, bugs in the new features when we added, I don't know, the postgres connection pool, and it turns out that it's got a memory leak. Well, yes, of course, we'll backport a fix to that, but not, you know, some fix that was released two versions ago, because people have worked around that by that time, and you break their work around, if you fix it in a minor in a point release, absolutely. And
Sarah Boyce 17:46
it's, I think it's part of the reason why I would encourage everybody not to, not to do the release from from LTS to LTS, because if you went from 4.2 to 5.2 and you tell us about a couple of things that were changed back in a 5.0 or 5.1 that have now caused issues, because you've only just started to test these. It's kind of too late, and we're going to be like, Oh, what a shame. And then you will only get those fixes, hopefully if someone does them by by 6.2 because if you're only going to upgrade them, then that's when you'll get it. But it won't go into a monthly it won't be back ported. So yeah, big benefits of staying up to date. Yeah. And
Carlton Gibson 18:34
if you're going LTS to LTS, it's going to be so if you find a bug that was introduced after 4.2 and you find that in 5.2 you're not going to get it till 6.2 because point two. That's
Will Vincent 18:45
kind of painful. I wonder if I could ask about the Django knot program, which, Sarah, you were very instrumental in setting up and still being involved with, just in terms of your life as fellows. Because I see on the Django news newsletter, we have Django knots, who come in and talk about the releases. Sarah, you started this trend, but it's double digit every week. So what is that, I guess. What is that? Has there been an uptick in quantity, or is it just quality? Or, I mean, I just looking at the numbers, see a change in contributions based on that program. Does that align with your experience.
Sarah Boyce 19:23
It's really hard to tell, because in terms of the the what we mentioned in the Django news updates is the points where things get merged, right? And the merging has a massive bottleneck in that there are only a couple of people who have merge rights, and they will always do they will always do another review, even if there is a review. And so in terms of. Like the number of pull requests that are getting raised and that require reviews and that, in theory, could be merged. It actually unless those things were really simple things, which we can merge very quickly, it doesn't often massively impact, like what we get through in a week by week basis. But I would say that it means that there are, like, people that are engaged in the process itself and trying to, you know, have new voices into discussions that have been, been going on for a while, and that that I feel like I can see more so than necessarily, the the number of commits. But yeah, I mean, I think it's been a really great way to encourage more people and to give them, like a route in that they perhaps didn't, didn't see themselves doing before, or at least if you're the kind of person who's just like, Yeah, I'll do it one day, and This will actually give you the the reason to dedicate some time and to get involved. But I'm curious what Natalia thinks, because obviously I'm very biased.
Natalia Bidart 21:31
Well, actually, from what you just said, I agree. But there is also in these programs, not only the Anglo space, also Google Summer of Code, there are mentors, whichever name we use for them, which are experienced the younger contributors, and will guide their mentees towards, ideally, a successful prb merge, and that process alone help the mergers as the viewers a lot in that we get PRs which have high quality that are not I mean, despite sometimes being complex or being non trivial, it we haven't, haven't had with have any numbers, but I will say that the review iterations that those requires to be merged might be less than if we will just get a real PR from someone that hasn't been mentored. So not only they have this support in order to start and be involved with the community in the various communication channels that we have, but also they start with, I will say, a quality of their proposal that is great and that help us a lot. And regarding that, there is also, mean Google Summer of Code and 502, which perhaps Sarah, you would like to mention a little bit, because it's all a little bit entangled what we have and the different you know, features and how these mentoring programs are keys to the new features that are being developed right now.
Sarah Boyce 23:22
Yeah so this Google Summer of Code period, we had three accepted projects. So we had automatic importings of models to the shell, which was a project that salvo has been working on, I'm pretty sure that will get in for 5.2
Will Vincent 23:50
no more Django extensions and run server, plus then,
Sarah Boyce 23:53
well, I mean,
Will Vincent 23:56
extensions has other great things, but that's for me that's always been like, the big reason I put it in just it's such a pain to deal with the shell and your models. So that's awesome.
Sarah Boyce 24:06
Yeah, it's really cool. And, yeah, I'm pretty confident that one's coming in that was mentored by buvnesh and Adam Johnson. Then there is a project by Ben, which he's been working on, which is like
Carlton Gibson 24:27
the oldest open ticket on, right? It's like 373, or something.
Sarah Boyce 24:33
Yes, I have no idea if he knew what he was getting into. That one is pretty intense. I mean, it's, it's intense, but he's been doing a really fantastic job. And like, the amount of progress that's been happening in this topic, you know, compared to the past few years, is. Is amazing. So I think it's unlikely that we will see that feature in 5.2 but I'm optimistic for 6.8 but we'll see there is then. There is a project by shahifa, which has been mentored by Sage, which is also quite a nice thing.
Carlton Gibson 25:28
So say Sage originally, Jason field in a Google Summer of Code, two, three, both, four versions.
Sarah Boyce 25:35
And I don't know this project so well, but I think this is Jason key transformations or something like this. And yeah, we'll see that will be a 5.2 6.0 candidate, I'm sure. But yes, so fantastic. I'm not sure how many projects we've had in the past, but it feels like a lot. And then there is actually, there's a fourth project. There is adding async support to Django debug toolbar, which is mentored by Tim Schilling. And that project, I believe, is being done by Iman Pandey, and from what I hear, it might already be done and released. So, yeah, congratulations. There amazing. This
Carlton Gibson 26:19
episode of Django chat is sponsored by talk Python. Are you serious about getting better at Python and web development? They have over 250 hours of courses, including their new HGM x plus Django course. Whether it's Django core Python or tooling you want to learn, you can save 10% and get a great course@talkpython.fm forward slash Django chat listeners with hyphens, level up your Python and support the show with the talk Python. Course links in your podcast, players, show notes. Now,
Will Vincent 26:44
well, I want to ask about so DjangoCon us is coming up, and I think all four of us are giving talks. Sarah, your talk is about what hidden features in Django, five point x. Are there any that we missed that you're going to be well, actually,
Sarah Boyce 26:57
I mean, when I say hidden, I mean, there's, I mean, I don't want to give too much away, yeah, sorry. Maybe
Will Vincent 27:05
that's too, that's too leading a question.
Sarah Boyce 27:08
But there's, there's a lot of stuff that we don't actually add to the release notes at all, so I want to actually give some of that work a stage. So that's, that's the idea.
Will Vincent 27:24
And then Natalia, you're, I'll just mention you're giving a keynote. What is the topic this year?
Natalia Bidart 27:30
The Django Fellowship is the topic. So when, I also don't want to be, I don't want to give a lot away, but when, when I got the position, actually, when I when I heard about the call for applicants, for the younger fellow, I had absolutely no idea what that was about. And I read the call for applicants, and I made this assumption in my head or around what was it about. I don't think it was that accurate. And also people, I mean, in my in my environment, in my friends or my family, will ask me, what is that? And there wasn't any clarity of what it is. So I would like to present what the diengo Fellowship is and also its value. And then some personal view and reflections around the fellowship and things that can happen around that.
Will Vincent 28:29
Great. Yeah. I mean, I know from just being on the board that the role of the fellows is really hidden from most people. So shining a light on that is important. And I have to say your talk last year, Natalia was my favorite talk of the whole conference. The inside out. That was amazing talk. So I'm looking forward to your keynote. Thank
Natalia Bidart 28:48
you. I was so nervous and have some technical difficulties, I'm looking forward to having the opportunity to give it again in some other context, because I think I will enjoy it a little bit more.
Will Vincent 29:01
So at DjangoCon Carlton, I are also giving talks, and one of the My talk is on the Django user model. And I want to tee that up as a question to you fellows, how do big decisions get made? Because one thing Carlton, I have been advocating for is making a change that goes beyond a Google Summer of Code, beyond what a Django not could do. And so what is your perspective on that? Because I think it was 2016 when the last there was a Kickstarter for a Postgres features were added. But it's, it's been a while. So could you share where you sit on these big decisions, like, let's, let's change something.
Sarah Boyce 29:36
Natalia, shall I go? All right. So on the So, just so people know, the fellows are not necessarily directing the future changes of Django. We're not, you know, there with a whiteboard and deciding what the what Django should. Look like for six point x, for example, we're very much in the day to day maintenance of things, and, you know, ensuring that the changes that go into Django are, you know, well tested, well documented, and following the processes as they should be. And it often means that when people come with suggestions to track, and people often do, they raise a ticket when they've got some new feature suggestion or they want to change something, it's not uncommon that we say, Oh, actually, this requires a wider discussion with the with the community. And part of the reason is we are just two voices, right? We we have some thoughts. We have some opinions, of course, but we don't necessarily know what's what's best, or how everyone is using Django in the different ways that they're using it. So in terms of when you want to make your changes, one of the advantages that you have is that, and I believe his name is Jake Howard or real orange, one has been working on he's just had a DEP accepted to hopefully have this background worker, inbuilt solution in Django core. And I think that was also had some momentum, also from a DjangoCon talk. I'm not sure if that was in just in DjangoCon Europe recently, or in one before. And then he was working on adep, which, you know, that got, like quite a lot of input and discussion around that at some point, once that feels ready, you can propose this gets voted on by the steering Council, and if the steering council votes to approve that, then that becomes accepted, and then you can now essentially work on implementing the, essentially the API changes, or the design changes that you had detailed in that document. I mean this, this is the idea of the like the larger decisions which require, you know, quite extensive reasoning and thought as to why we want to do these kind of changes. Because, generally, Django doesn't want to break things, so it needs to be really justified when we when we do this. And I would say, you're right, it doesn't happen so often, and in a way, because of Google Summer of Code has They also write like a project document. In a way, they've been doing a similar kind of justification of research and stuff when they apply to, perhaps add in, you know, composite primary keys as an example. But yes, in theory, we should be doing depths for for all of these changes, and that gets the review from the community. But it's not entirely defined. Like, what is the boundary of of when it's depth worthy and when it's not? It's a little bit gray, but
Carlton Gibson 33:23
like all like, all natural boundaries, every division in the world, there are cases that are clearly one sided. Cases are clearly the other and have sort of middle in a bit where we're not quite sure, right? That's totally normal. I think what happens is we can't get an agreement. It's not just like normally, 95% of ideas are either yes or no, and everyone's on board. And then sometimes it's a bit, well, hang on. This is a bit more, you know. And if you're at work and you say, can we implement this new feature, it's not unreasonable for them to say, can you spec it up first? Yes, right? Which is kind of what a deck writing the depths that spec it up first bit. I think we make it a little bit too formal, if anything, but the idea is right,
Natalia Bidart 34:04
and particularly regarding your question, well, one of the things that Jake did that I think is super helpful for something to get traction, is to provide whatever feature or idea you are proposing as a third party package. So currently, the Anglo task is a package that exists that you can install and that is getting updates and features and pull requests. And it will also, at some point, when the Anglo task gets merged into the angle main it will serve as a transition package for all the versions of the angle to adopt it and then be able to keep upgrading the angle and keep using the same interface for the background workers. So having something like that for whatever you're planning, which I'm very curious and. To Know About would be a good way, a good path forward.
Will Vincent 35:05
I would say that it's more I'm trying to be the cheerleader here. I mean, Carlton has a third party package, for example, Django, unique user email
Carlton Gibson 35:15
that Yeah. I mean, so that, yes. The idea there is just to enable login by email by making the unique, the email field unique. And I always felt that custom, if you just want login by email, custom user models were a big, quite sledgehammer to crack that little particular nut. And so it's and the reason why we didn't migrate or user back in the day was it was felt it was impossible, but, well, hang on, you can just have this little bolt on option, and there's your unique email, and the same with the profile fields that I want to you know, I'm working on proof of concept there, if you don't, if you want to hide those from the model there, you can and so forth. I think there is a route forward for author user, which doesn't require every project already out there to do a painful set of migrations. There are more subtle ways that we could go about it. And I think that that it just in the author, you in the authorization, end of it, that cut that. So when we had the A while back, Tebow ran a work roadmap workshop, and the number one issue, the number one thing everyone said was, let's update contributor, dot Orth, right? Let's, let's make auth in Django a better thing. Well, okay, we need a way. We need a roadmap forward. So what I'm working on at the moment is proofs of concept of, well, you know, we could perhaps go this way, we could perhaps go that way. And then I'm hoping that we can get the community and the very clever people in the community to help me think through the harder problems about, well, okay, if we're realistically going to do that, what about this case and that case? In this case, because, you know, my proof of concept is something I knock up in an afternoon or a week or and that's not quite the same thing.
Will Vincent 36:53
Well, because it feels like if I've waved a wand, off, off. Auth is one of the areas where Django is not as forward looking as it should be, right? I mean, for historical reasons, the Model User models from 2003 or so, but not having two factor auth, not having Social Auth, not having, you know, working with past keys. I mean, the current status is, personally, I rely on Django, all off which Raymond penners has worked on for forever, and I know he just got a grant that to me, that's kind of been a kludge that papers over some of these problems. But, you know, newcomers come in and say, this is way too much confusion around authentication, essentially. So that would be, that would be the overall goal. But my talk is gonna be a lot more about the past and the present and then kind of leading up to the future. But again, all this was in 2012 like all this happened, you can see the discussions. Things got heated, and that led to custom user models. And I think the argument that Carlton and I would make is that that doesn't really solve the problem, but in practice, and I'm sure you'd agree most people separate from the logging in and out how you deal with information about the user, you either use a user profile model or you use a custom user model, and that's fine to have a split, but that's deeply confusing to people I'm trying to teach, or people who come in or it would be better if there was one way, which I know is hard for the Django community to align around. So there's the model itself, and then there's, how do you attach information to it?
Natalia Bidart 38:27
And there is a third one, if you ask me, which is splitting authentication from authorization. Yeah.
Will Vincent 38:35
So what would you do? Where's your wand? What would you Natalia? Take off your fellow hat? How would you fix everything?
Natalia Bidart 38:42
I'm not entirely sure I haven't given this like a serious thought, but in my experience, when working with user, a decent sized service may usually need to authenticate every so often. But my need to authorize, authorize, sorry, a user very often. So the this, the needs to fulfill those different type of requests, is a little bit different. So to me, the first gut reaction is that we need to split those out, being able to authenticate, from being able to authorize a user to do a certain actions in a way that we can then in production, deploy that with different abilities and different constraints or different scalability features, because Your authorization service will have usually a higher rate of request than the authentication service. So my first instinct is to split those two in a way that I can scale them differently. Yeah, no,
Carlton Gibson 39:53
I agree. The other thing I'd really want to do is be able to, like, have kind of levels of authentication. So, you know, you might log in with just a four. And you get your session cookie, and that's fine for browsing around, but if I suddenly want to go into the settings and update my email, maybe change my account email, or maybe I need to re authenticate. Maybe I need to use my two factor auth in order to do that, because that's a kind of more high risk activity. And to have grades of, you know, grades of who are you would be nice. Um, so there's lots we could do. Um, there's lots we could well, so
Will Vincent 40:27
that's, that's, that's my hope, that there's momentum and agreement coming out of DjangoCon us that this is worthy of, not just worthy of focus, but can have those discussions around, okay, what is, what is the path? Is it, you know, can we, you know, write it out on a napkin in the hallway on like, what? What might a depth look like? What might a third party package look like? To address some of these things, the issue is that it's, it's a lot of work. It's a lot of work. So it's, that's kind of the other piece, where maybe the the Django Software Foundation and others come in is it feels to me like something that might require some funding, which Django itself hasn't historically done, but I'm not in the board anymore. So I feel like Django could, and should, you know, periodically, find funding for major, major projects that the community gets behind. But that's, I guess that's another piece on the puzzle here, but I feel, I feel like that's in some ways the easiest, like, if there was consensus, and okay, we could find someone who could, we could find someone qualified if there was agreement, and we could find a way to raise the money for three months, whatever the time period is, to pay them to do that. Carlton, yes. Anything you want to add,
Carlton Gibson 41:39
I get slightly, well, yeah, I just get cold, slightly cold shivers hearing you talk that because the battle scars have too many Django decisions.
Will Vincent 41:47
Yeah, well, I'm, I'm newer than you. Carlton and the fellows are newer than I am. So on this type of thing. So
Carlton Gibson 41:56
Django, Danielle asked me a question off in after my talk about whether we dodged, sometimes dodged a bullet, like Django is very much like, what was it about? I can't remember what it was about, bringing in DRF into core. So 5678, years ago, the idea was, yeah, let's just merge DRF into Django core. And now all this time later, it didn't happen. And actually, you look around, you think the API space is so exciting, you know, let's not just take one thing and crown it. Let's let the 1000 flowers bloom and let's see how they all grow. And so Django is, in a way, in that sense, Django really slow and really painful decision process actually saved us from doing something which would perhaps looked good at the time, but would have then limited us going forward. And I know I think sometimes the slowness is good, but it is really hard to get these changes. I don't know. I mean, you're, you're, you're there, dealing with it, both of you all the time. I mean, it was what it's one of the hardest things that the fellow, yes,
Natalia Bidart 42:54
I, for me, the hardest is the lack of clarity on that. Because I know now, but I don't think that we as everyone is clear about how hard it is and how perhaps intentionally undefined is, and that, to me, is very frustrating. And I feel that for contributors is also quite frustrating, because I think there are mixed expectations around that that is something that I would like to see more clear, not necessarily more more streamlined, or make changes more easy, no, but being able to clearly state what will be the process and what it entails, even though that says it's very difficult to change.
Carlton Gibson 43:48
I know Jacob Kaplan Moss had some ideas on this a while back. Is that there's a thread on the forum about it, and I'm hoping he's going to pick that up and push that just to the next level at some point. So if you see him, you should say Natalia. I might see him at DjangoCon. I might say to myself,
Will Vincent 44:04
I want to add in terms of dodging bullets, I mean templates, I think has borne out, you know, so Django approach of not embracing our more full, bloated Django templating system has now led to the fact that HCM X smoothly slides in, and we don't have, you know, our version of React or something that we have to deal with. So that's another example of staying small. And there was certainly moment momentum, maybe 10 years ago, around Django templating should do more, but the fact that we didn't, and it's minimal and as painful. I mean, this is sort of like the my startup. One of my startups experience was at this company called Quizlet, which is Quizlet, which is education flashcards, and it's grown and grown and grown, which has been great, but on the inside, it's grown in part because we couldn't ship new features, which was incredibly frustrating, and people left over it internally, but it turned out long term that was best for the business, just to, like, keep it going and not not change. Too much. But when you're fighting, when you're in the day to day, you want to, you want to do things right and so that you need somewhere to put that frustration anyways. It's a universal thing, I guess, even though maybe long term, it's best for a project, it's not best for the people keeping it going.
Sarah Boyce 45:15
I mean, that's the it's the I think people don't appreciate that. It's not like the issue is, is that we need to get 20 people in a room and just talk about it, because that's usually what will happen in a in a company, is that you've got, you have a limited number of developers. In theory, you could do, you mean, even with a very big team, you could do some kind of like, off site event, and you talk about it, and blah, blah, blah, and you get everybody on board and find that's what you're doing now. And that kind of breaking changes is something that you are willing to do, and that you will be able to do that. But with Django, in reality, actually, the number of people who discuss a lot of the changes in quite a lot of depth is a relatively smallish group who are regularly adding their voices into the discussions. I mean, it's not unusual that we'll get new people with new ideas, but they're not necessarily adding their voices to other such open discussions. And I think with the stability element of it, even little, really little things as to like how we've named it, but someone wants to change that. In theory, we would deprecate it to add a better, better name. And so it's not really a place for experimentation that we can just, you know, yeah, let's just throw it out there and see what people say, necessarily. Because, you know, it'll take eight months or longer for deprecations to really come into business. And yeah. So anyway, it's, it's definitely a lot more complicated than what people are perhaps used to in their in their day jobs. And if we, you know, cycle back to juggernaut space, I would say that's one of the main things. Is, for me, is really this kind of expectation management and just kind of talking to people about, you know what? What is kind of normal in with Django contributing but perhaps this is normal in many open source contributing spaces around you know how long things take, how long you should expect before you ping someone for a reply, or, you know, the discussions about, you know, whether you've, you've actually, because two people thought that was a good idea. Does that mean it's a good idea and all this kind of stuff? And, yeah, anyway, it's definitely, it's tough. And I don't know how to make it easier, but yeah, it's definitely tough.
Carlton Gibson 48:06
There's a online guide to running an open sales project by the curl maintainer, and it's called everything curl and in there, and he talks about running the project, and he's been doing it, I know, 30 years or something, some obscene amount of time now, but he's got a whole chapter on people, and he's absolutely clear that the people side of it is the hardest problem. Is the hardest bit it? It just is, like this technical problem. Yeah, we can bash our way around that, but negotiating the different requirements and the different needs that's that's the work. That's the label.
Will Vincent 48:43
I mean, I think this is relevant too, because so Yes, yesterday it was announced that layer, Laravel, which is the PHP framework, which is probably one of the ones most similar to Django, raised $57 million from, you know, Excel to do cloud hosting and stuff. And so they're inevitably the questions about, well, why can't Django do things like that? And it's important to say, well, Laravel is one person. This guy, Taylor. I mean, there's open source, but it's his thing. He can decide what he can do, and part of that is monetize and do all these other things. And while it's easy to sort of look and say, Oh, I wish we could move fast, there's, I mean, I worked with this project called Meteor Js for a couple years. That was a VC funded framework that was trying to make money off hosting, and it's gone, gone, right? So the when you raise money and you go fast, you end up often not working in the long term, right? The fact that Django is what 1820, years old is because of this slowness 19 years and also, I think also, it's important to mention the fact that we because Django doesn't rely on one person, it can have longevity. Right? At some point all this stuff eats away at you, or your life changes and you don't want to do it. But Django can persist. I mean, look, look at Jacob Kaplan Moss, right? He's. A good example, I think, right, one of the creators deeply, deeply involved, and he's always been around, but he was a little bit less involved for a number of years, and now he's back on the board and doing things, but it's not, you know, it's not, it's not the Jacob show, and he wouldn't want that. So I guess that perspective is important to keep in mind, as easy it is to see the shining lights like that's kind of why we're we're still here. And, yeah, things but, but there is a, there is a cost to the the internal side of especially being a Fellow, right? Like, you know, does is it something that people can only do for five years? You know, is five years too long, right? Maybe there's ways the DSF, the community, can do to not have it bubble up and feel overwhelming at a certain point. I don't know that. Maybe that's a hallway track discussion
Natalia Bidart 50:48
we'll see. So I
Will Vincent 50:50
think we're coming near the end. Are there any topics for either Sarah, you or Natalia that we haven't mentioned, that you'd like to raise Sarah? Why don't you go first?
Sarah Boyce 51:01
Well, we already talked about Django knot space, but I will just reiterate it that we're coming towards our third session of the year. I think by the time this goes out, the applications for Django knots will be closed. However, hopefully there will be sessions next year. And really, as with everything, it's more gaining the mentors, gaining the volunteers to help run these sessions that that is the bottleneck. So if you want to, if you have capacity, and this is something you'd be interested in doing. Please do reach out to the organizers, and I'm sure we'll do something next year with you.
Natalia Bidart 51:47
Okay? And for me, on a similar topic, something that I have seen and I'm now extremely convinced, is that Django is progressing, and it is what it is because of the contribution of all the community and the people that tries to help and make the framework remains current and grow. And there is how things are right now, I don't see a way for the fellows to keep it progressing, and fellows on their own to keep it progressing and being stable and something against feature. We desperately need the community to be involved, to help in whatever way that you can either be writing code documentation, mentoring or doing reviews, doing bug trials, attending to conference and talking to us and bringing ideas. I think that's key, key to the point that it's the difference between the angle remaining and not remaining. So that is also something that I want to touch in my talk. How I think that's fundamental and we I think that if I could ask for any more resources to reboot somewhere, that will be one thing that I think that we should prioritize. Carlton,
Will Vincent 53:08
do you have any as a fellow alum? Comments, yeah,
Carlton Gibson 53:12
no. Like, that's absolutely true. I always described it as being the janitor, right? You keep the floor clean like but Django is progressed by its contributors. And the purpose of the fellows is not to push the framework forward. The purpose of the fellows is to give the space for the contributors to get on and do the things they want to do, rather than trying to merge four patches onto four security patches onto five branches just to get them all out on a security release. No, that's the fellow's job. That's not, you know, the contributors job, yeah, so I absolutely agree with that. I, you know, we swept the floor, right? Thank
Will Vincent 53:49
you both for coming on. I hope this becomes a regular thing, because one of the goals of this podcast is to shine a light on the community. And I, I felt like the fellows kind of operated in the dark historically. So now that people, if they didn't already, they know who you are, but they also understand how the role fits into the community and things everyone can do to make it more maintainable. So with all that, we'll have links to everything we are at Django, chat.com, and again, thank you both for coming on. Thank
Natalia Bidart 54:18
you for having me. Thanks
Carlton Gibson 54:18
very much. Thank
Sarah Boyce 54:19
you so much. All
Will Vincent 54:20
right, we'll see everyone next time bye
Carlton Gibson 54:22
bye, bye bye.
This episode was brought to you by talk Python and their new hmx plus Django courses.