Skip to content

Enhance startapp Command for Nested App Creation and Correct AppConfig.name Generation #62

@kiraware

Description

@kiraware

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:

  1. 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 a CommandError: Destination directory '...' does not exist, please create it first. This adds an unnecessary manual step to the app creation process. Developers are forced to mkdir the parent directory before running startapp, which is an inconvenient and interruptive hurdle. This friction discourages adherence to a clean, nested app structure.

  2. 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 within apps.py correctly reflects the app's simple name (e.g., name = 'blog'). However, when startapp is used to create an app within a nested path (e.g., python manage.py startapp blog apps/blog), the AppConfig.name attribute still incorrectly defaults to just the app's immediate name (e.g., name = 'blog'). The correct value for a nested app like apps/blog should be name = 'apps.blog', reflecting its full Python import path. This discrepancy forces developers to manually edit the apps.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):

  1. Developer wants to create myproject/apps/blog/.
  2. Developer runs python manage.py startapp blog apps/blog.
  3. Command fails with CommandError.
  4. Developer must manually run mkdir apps or mkdir apps/blog.
  5. Developer re-runs python manage.py startapp blog apps/blog.
  6. Command succeeds, creating myproject/apps/blog/ and myproject/apps/blog/apps.py.
  7. Developer opens myproject/apps/blog/apps.py.
  8. Finds name = 'blog'.
  9. Developer must manually change it to name = 'apps.blog'.

Desired Workflow (Proposed):

  1. Developer wants to create myproject/apps/blog/.
  2. Developer runs python manage.py startapp blog apps/blog.
  3. Command automatically creates apps/ or apps/blog/ directory if it doesn't exist.
  4. Command creates myproject/apps/blog/ and myproject/apps/blog/apps.py.
  5. Developer opens myproject/apps/blog/apps.py.
  6. Finds name = 'apps.blog'.
  7. 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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    Idea

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions