Django: Moving away from project vs app dichotomy

Kamal Mustafa - Apr 8 '18 - - Dev Community

I was looking at one of exercise of a developer learning how to build app using Django. His directory structure look like this:-

ceri main manage.py ...
Enter fullscreen mode Exit fullscreen mode

ceri is the chosen name for this project. But looking deeper in each directory, you'll see that ceri contain only settings.py while in main there's views.py, models.py etc. Directory main basically the meat of this application. I'm baffled looking at this.

They probably following Django tutorial and start with:-

django-admin startproject ceri
Enter fullscreen mode Exit fullscreen mode

Since the "project", at business level is called "ceri", it's logical for this developer to run startproject using "ceri" as well. But then he came to next thing the tutorial ask him to do:-

django-admin startapp ...
Enter fullscreen mode Exit fullscreen mode

My guess is the dev will stuck for a while thinking for the appropriate name. Giving up, he just pick "main" for the name.

This "app" vs "project" IMHO is unnecessary to the beginner. There's nothing that prevent you from putting all your views and models in ceri directory but newbie to Django will be given impression that these "project" vs "app" is required thing. The argument for this is to encourage writing reusable apps from the beginning. If you write your "app" generic enough, you can just plug that app into another project.

But 80% of the time, you'll just writing app that specific to that project. Most often, people will pick a generic name for their apps such as "user", "order", "customer" etc, convulating the top namespace. I bet that they will hit situation where third party package they want to use clash with their generically named app first than a situation where they want to reuse their app.

It's not that developer should be discouraged from writing generic app but this can be introduced at later chapter. We can reduced confusion and this kind of question at Stackoverflow.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .