Django: Moving away from project vs app dichotomy
Kamal Mustafa Apr 8
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 ...
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
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
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 ...
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.