"Project" Naming Conventions

Using Django Getting Started
1

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.

3 Likes
2

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!

2 Likes
3

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
4

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
5

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.

6 Likes
6

Just to be clear, does that mean you start all new projects with: django-admin startproject config .

7

That looks right to me. I normally rename config to “{project_name}-git”, cd into it, run git init, and then I start using the project.

99% of the time, I am using a pre-existing startproject either from work or one of my own. Here is one I have used that has the layout like I suggested: https://github.com/jefftriplett/django-startproject

8

Hey thanks for the reply and for the link to your starter project. Over the last couple of weeks I’ve been building my own version of a starter project too, and since renaming the base project to “config”, it just makes so much more sense.

cheers.
stuart

1 Like
9

I started off with the normal project name,

Then moved to project,

Then my server-side teammate recommended (if anything) to use config because it made more sense in production.

So ever since then config, and really, it just makes the most sense because it’s a glorified settings.py file. Therefore, config.

Normally when making a project from scratch I just create a new folder, name it the name of the project, then run django-admin startproject config . inside that folder directory. And poof! New project properly made.

10

I know we’re descending into serious bikeshedding territory, but I’ll add a thought about why I use project.

My project directory contains:

project
├── __init__.py
├── asgi.py
├── settings.py
├── testing_settings.py
├── urls.py
└── wsgi.py

IMO, asgi, wsgi, and urls (debatedly) don’t seem like configuration. I also find that “config” and “settings” read as synonyms to me so it’s confusing to me to have config.settings.

I agree with @ekerstein that the name selection is “very personal.” I’m not throwing shade at anyone that selects config as it’s a totally reasonable choice. I’m hoping to share my rationale for why someone might choose project. :smile:

1 Like
11

Yeah yeah. I also do prefer this.
(especially that part where config.settings not sounding that convenient :wink:)
An alternative I have been using for some time now is using core for the project name such that you may end up having:
core.settings
core.urls
…
Some time ago, I used to give the project a general name related to its purpose, like say I am building an ecomerce sites called travelshop, I would then name my project ecommerce and the app would take the brand name, in this case being travelshop.
I think the answer to this ends up with one’s own personal preference, and maybe their project layout as well.

12

Personally I like base.

base.settings, base.urls, etc just seems to work.

1 Like
13

Sorry for bumping up an old thread but why not use the THUNDER scheme. THUNDER stands for THree UNDERscores.

md yourprojectdir
cd yourprojectdir

# create your pipenv environment of whatever you use

django-admin startproject ___ .

For each real project, naming in Django the project as “___” has the following benefits:

  1. It’s a valid python variable/dir name.
  2. standardizes naming convention for a directory that’s always present in a Django project
  3. No trouble when jumping between projects, all have settings.py/etc in the same dir
  4. No name collision with possible apps since there is no name
  5. Simple & short
  6. No confusion when reading, no mental translation or name association needed

    from ___.settings import ROOT_URLCONF

    from ___.urls import *

  7. Easily floats-to-top or sinks-to-bottom in dir listings
  8. In VSCode floats to top, even above your (dot)xxx dirs, clearly separating your main config files from your application structure.

Any thoughts?

Best regards
Alex

1 Like