"Project" Naming Conventions

Django newb here, I have seen a few articles touching on this topic but nothing that answered the question for me. I’m wondering how people prefer to name their project in Django.

I’ve seen a variety of different ways: “project”, “config”, or even “app”. This is probably very personal but I’m wondering the best practices other people have found works best for them.

When I’m glancing at my folder list in my Django project I would prefer if the project directory (with settings, urls, and other sitewide configurations) stands out among the “apps”. What have other people found works best? Right now I just call the folder “project” but not sure if that’s best.

I just use the standard django-cookiecutter template, which puts all config files in config. It also suggests putting all your apps within one folder, together, to avoid namespace clashes with third-party apps, but also to group them together more obviously. I’ve found both conventions good!

1 Like

If we’re talking about namespacing, my preference is to have a myproject package which contains the apps, e.g. myproject.myapp, as well as settings at myproject.settings, and the manage.py script at myproject.__main__ (so that you can do python -m myproject).

We don’t anymore (we’ve since switched to using Docker) but at work we used to deploy our Django projects as wheels, and this setup avoids namespace clashes (as @takkaria pointed out in their suggestion as well). It also makes the repo structure a little clearer than having all of your apps in the global namespace and thus the root of your repo, IMO.

2 Likes

I usually stay with what django-admin startproject myproject creates. The reasons:

  • I think most people who know Django will be familiar with that (for example from the tutorial).
  • Some bits of the official documentation more or less assume this structure, IIRC.
  • I’m used to it :slight_smile:
#
rene@rene-desktop tmp % django-admin startproject myproject
rene@rene-desktop tmp % tree myproject
myproject
├── manage.py
└── myproject
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py
#
rene@rene-desktop tmp % cd myproject
rene@rene-desktop myproject % ./manage.py startapp myapp
rene@rene-desktop myproject % tree
.
├── manage.py
├── myapp
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
└── myproject
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

I know that some people dislike having two nested directories with the same name (myproject/myproject). In this case, I recommend to rename the outer myproject directory. You can do this without having to adjust any import paths (only the inner myproject directory is a Python package). If the outer myproject directory also is the repository root, it is even possible for each developer to use their own local name without interfering with others:

git clone https://example.org/myproject my-preferred-name
cd my-preferred-name
# ...
1 Like

I switched to config several years ago, and I honestly haven’t looked back. It’s nice switching projects without having to look for a myprojectname which is inconsistent from project to project. This makes finding settings less of a memory game if you have a bunch of projects. I have a few hundred that I bounce between.

I use config.settings and config.test_settings for my two settings files so that everything is standardized. Using config makes it a bit easier to share Docker files and other random bits without having to run a find and replace it as much. So back-porting some fixes or improvements are much easier.

I don’t think the naming scheme matters, but I find it easier to have a set pattern, and config floats to the top more naturally, too.

2 Likes