-
Notifications
You must be signed in to change notification settings - Fork 2
Description
Code of Conduct
- I agree to follow Django's Code of Conduct
Feature Description
Enhance the startapp
command to automatically create parent directories when a nested app path is provided, and to correctly generate the AppConfig.name
attribute to reflect the full Python import path (e.g., apps.blog
instead of just blog
).
Problem
Many Django projects, especially larger ones, organize their applications within a dedicated "apps" directory (e.g., myproject/apps/blog/
). This approach improves project structure and maintainability by preventing the root directory from becoming cluttered with numerous app folders. Currently, however, Django's startapp
command presents two significant usability issues for developers adopting this common pattern:
-
Manual Directory Creation Requirement: When attempting to create a new app within a subdirectory using
python manage.py startapp <app_name> <path/to/app>
, the command fails if the specified parent directory (e.g.,apps/
,apps/blog/
) does not already exist. The developer is met with aCommandError: Destination directory '...' does not exist, please create it first
. This adds an unnecessary manual step to the app creation process. Developers are forced tomkdir
the parent directory before runningstartapp
, which is an inconvenient and interruptive hurdle. This friction discourages adherence to a clean, nested app structure. -
Incorrect
AppConfig.name
Generation for Nested Apps: When an app is generated at the root level (e.g.,python manage.py startapp blog
), the name attribute withinapps.py
correctly reflects the app's simple name (e.g.,name = 'blog'
). However, whenstartapp
is used to create an app within a nested path (e.g.,python manage.py startapp blog apps/blog
), theAppConfig.name
attribute still incorrectly defaults to just the app's immediate name (e.g.,name = 'blog'
). The correct value for a nested app likeapps/blog
should bename = 'apps.blog'
, reflecting its full Python import path. This discrepancy forces developers to manually edit theapps.py
file immediately after creation, a repetitive and error-prone task that can lead to subtle import issues or app loading problems if overlooked.
These problems collectively reduce developer efficiency and introduce unnecessary friction for a widely adopted project organization strategy.
Request or proposal
request
Additional Details
Current Workflow (Problematic):
- Developer wants to create
myproject/apps/blog/
. - Developer runs
python manage.py startapp blog apps/blog
. - Command fails with
CommandError
. - Developer must manually run
mkdir apps
ormkdir apps/blog
. - Developer re-runs
python manage.py startapp blog apps/blog
. - Command succeeds, creating
myproject/apps/blog/
andmyproject/apps/blog/apps.py
. - Developer opens
myproject/apps/blog/apps.py
. - Finds
name = 'blog'
. - Developer must manually change it to
name = 'apps.blog'
.
Desired Workflow (Proposed):
- Developer wants to create
myproject/apps/blog/
. - Developer runs
python manage.py startapp blog apps/blog
. - Command automatically creates
apps/
orapps/blog/
directory if it doesn't exist. - Command creates
myproject/apps/blog/
andmyproject/apps/blog/apps.py
. - Developer opens
myproject/apps/blog/apps.py
. - Finds
name = 'apps.blog'
. - No manual changes required.
This enhancement aligns with the principle of "batteries included" and significantly improves the out-of-the-box experience for structuring larger Django projects. It also prevents common configuration mistakes related to AppConfig.name
.
Implementation Suggestions
No response
Metadata
Metadata
Assignees
Labels
Type
Projects
Status