Django New Project Structure/Name

I’m curious how the community is naming new Django projects these days.

In the past, in my books I recommended something like books_project or blog_project as the name to keep it clear vs apps. A while back I switched to config as a default across my projects and books. Recently, however, several teachers have told me that config is confusing to their students. Especially for students using PyCharm.

My sense is that project naming and directory structure varies quite a lot in the wild. So I’m curious what’s being used these days. And any thoughts on what would be clearest to those new to Django.

Thanks!

1 Like

I don’t think it matters what it’s called. I picked config years ago because it bubbles up to the top of a list of folders/files, it’s not clever, and it’s mentally easier to remember in big projects than {app_name}_project like everything else I had worked with leading up to it.

One could argue that project is a better name because you create it with python manage.py startproject. I think calling your web app “project” would be more confusing for new people because most people don’t even know what a project is. Most IDEs have a completely different set of opinions and features for projects as well, which doesn’t help.

In a perfect world, I would rename/merge startproject and startapp into one command, and I would call my default app+config just app, but going against ~16 years of Django material, so that’s out.

If you work on more than one project, I recommend standardizing one config folder name for all of your web applications/projects. Bonus points for being sort friendly so that it’s easier to locate.

In the medium to long term, I think standardizing to one config/project naming scheme is better because it makes copying and pasting configs between projects less problematic for people.

When in doubt, use config until you can come up with a better name.

2 Likes

I keep my projects inside a single Python package these days, and the apps as submodules within that. For example, for a project called books with two apps called core and loans:

books/
    core/
    loans/
    __init__.py
    settings.py

I normally have only one app called core. But when splitting things out into multiple apps, core is a good place for “base functionality” e.g. custom user model, custom model subclasses, etc.

It’s also possible to have the “project” module also be its one and only app:

books/
    __init__.py
    models.py
    settings.py

I think this is pretty beginner friendly, it’s what you’d when expanding up from one file in smaller frameworks like Flask. It’s just harder to split into multiple apps later, but is that really needed most of the time?:man_shrugging:

2 Likes

I am actually a big fan of config (or core) and would say keep it. Just maybe a brief explanation in the books(if not there already) on directory structure and why it matters - and Django defaults v. Common Patterns.

I don’t think there is anything consistent in the wild, and config is a pretty reasonable pattern.

1 Like

In my lat project I use:

my_project/
    app/
        app1
        app2
        ..
    config/ -> This is the Django Project directory
        base.py
        production.py
        development.py
    templates/
    tests/
    utils/ -> A directory for non-specific-app stuff
        helpers.py
        validators.py
        views.py
    activate -> a symbolic link to my venv activate file
    manage.py
    requirements.txt
   .gitignore
    ...

I am very happy with the layout.