TLDR: I’m happy to see that DEP 15 was accepted. There have been many interesting discussions over the years about how a Django project should be structured, and this DEP provides a way to support a variety of modern approaches to structuring Django projects, while maintaining backwards compatibility.
The main thing I want to see moving forward is consistency and predictability. I’ve spent a lot of time teaching beginners Django, and I’ve also been working on django-simple-deploy. Both of those experiences heavily influence my thinking around project structure, and the tooling we offer people out of the box and through the third-party ecosystem.
Teaching and learning Django
Last year, I wrote a series called Django from first principles. It starts with a minimal single-file Django project, and builds a full blog hosting site. New files and directories are only introduced as they’re needed. The end state is a project structure that mostly matches what you get from running startproject. The main feedback I’ve gotten from people who’ve worked through it is that they come away with a much better understanding of why startproject generates the “complex” structure it currently does. (The takeaway isn’t that people should build projects this way. I conclude by stating that people should run startproject with an understanding of why that complexity in project structure is introduced right away.)
I’m a big fan of offering a template that puts one starting app in the main project. It’s surprising and confusing to people that they have to run two separate commands just to get a Django project working. It pushes everyone who teaches Django, formally or informally, into an immediate discussion of “apps” vs “projects”, with nomenclature that predates today’s common understanding of what an app is. It would be very nice to get past this.
Consistency and predictability
I’ve been working on django-simple-deploy for a while now, and it’s been well received. In the course of this work, I wrote a demo flask-simple-deploy, and later a demo fastapi-simple-deploy. I never intended to release these; they were just experiments to see what it would take to build a similar tool in those worlds. It was easy enough to get a toy demo working for both of those projects. However, it would have been much harder to build out a meaningful real-world version of either project, because there’s less consistency in overall project structure in those worlds.
I really don’t want to see an explosion in different kinds of project structures in the Django world. We gain a lot by having consistency across projects. There will always be variety in project structures, but the more we stay within some well-known patterns, the better off we all are. I wonder how many third-party packages base some of their functionality off of known consistent patterns in Django project structure.
I’m wary of a single-file template that doesn’t offer a clear path toward a known project structure. I don’t want to see Django turn into Flask because we start offering a single-file project template, and then leave those users to figure out effective web app project structure for themselves. One of the reasons I keep an eye on nanodjango is because of the convert command. You start with a single file, but when you want to break out of that you run convert and move to a predictable, consistent project structure.
Opinions are good, and I’ve always loved Django because it contains the opinions of people much more experienced than I am. Let’s continue to evolve, but let’s continue to steer people toward opinionated approaches as well.
else?