Applications Folder

[smrf1093]

Description

Move all the application folders into a subfolder named apps

Rationale

It is more logical to have all Django applications in one subfolder, here is a StackOverflow discussion which suggests this
https://stackoverflow.com/questions/22841764/best-practice-for-django-project-working-directory-structure

[Andrew-Chen-Wang]

Isn't it already under one sub folder called the "project_slug"?

[smrf1093]

There are static, templates, utils alongside users in one folder its better to move users and others applications in a subfolder called apps in this directory

[luzfcb]

The current layout of the project has been working well for the last 7-8 years. I don't remember any previous questioning of the current project layout.
That said, it would probably be better to argue over a proof of concept. Feel free to submit a pull-request

[browniebroke]

@smrf1093 would you find it less confusing if folders for non-apps were outside of the project_slug folder? I kind of see what you mean, but at the same time I don't really see the need for another level called apps. The main drawback I see is that it would increase the length of all the imports:

- from project_slug.users.forms import ...
+ from project_slug.apps.users.forms import ...

Although on a second thought, I would like to leave the utils package where it is, as it enables us to easily namespace isort's known 1st party:

cookiecutter-django/{{cookiecutter.project_slug}}/setup.cfg

Line 11 in d2f129e

known_first_party = {{cookiecutter.project_slug}},config

[smrf1093]

@browniebroke I nearly agree with your suggestion at least we know all the apps are placed inside the project_slug folder and this scope is restricted to the Django project applications. about the lengthy imports, I do not completely agree with you because just adding 4 characters to the imports does not make them lengthy besides it adds meaning to it for example when you write project_slug.apps.devices it means that the devices package contains a Django application

[browniebroke]

Granted, it's not many characters on a single line, but it would be repeated many times, for nearly all internal imports of the project. I think that cost is not worth it as I see no benefit (at least so far).

[huydbui]

@browniebroke I nearly agree with your suggestion at least we know all the apps are placed inside the project_slug folder and this scope is restricted to the Django project applications. about the lengthy imports, I do not completely agree with you because just adding 4 characters to the imports does not make them lengthy besides it adds meaning to it for example when you write project_slug.apps.devices it means that the devices package contains a Django application

These implementations are more like user preferences, you don't need to wait for them. I have been using it for years. All of my apps (just my apps) are in an "apps" (or similar name) folder. I mostly use relative imports between apps, so I don't see the "apps." in my imports at all.

[smrf1093]

@browniebroke I nearly agree with your suggestion at least we know all the apps are placed inside the project_slug folder and this scope is restricted to the Django project applications. about the lengthy imports, I do not completely agree with you because just adding 4 characters to the imports does not make them lengthy besides it adds meaning to it for example when you write project_slug.apps.devices it means that the devices package contains a Django application

These implementations are more like user preferences, you don't need to wait for them. I have been using it for years. All of my apps (just my apps) are in an "apps" (or similar name) folder. I mostly use relative imports between apps, so I don't see the "apps." in my imports at all.

Yes, I know it is a user preference. However, many of the cookie-cutter structures can be changed based on user preferences, but the purpose of it is to present a good starting structure. So, based on the purpose it is better to have this feature included.