Open smrf1093 opened 2 years ago
Isn't it already under one sub folder called the "project_slug"?
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
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
@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:
@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
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).
@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.
@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.
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