A command line utility for starting Django projects and apps in a most classy manner.
-
Install
django-classy-start
withpip
(in your virtual environment).$ pip install django-classy-start
-
Start a project
$ classy-start project <project-name> .
This initializes a project named
project-name
in the current working directory. In addition to the regular Django stuff, project is initialized with:- an
accounts
app containing a custom auth user model - a
.env
file with default project secrets - and more
All of these are reflected in your settings file, so you don't have to bother yourself with wiring them up.
- an
-
Start your apps this way
$ classy-start app <app-name>
Your settings file isn't touched for this operation, though.
The Django docs on auth (customizing) recommends setting up a custom user model for every new project as it's usually a real pain to change the auth user model after the database tables have been created.
And while it's easy in theory for everyone to remember to set up their auth user model first thing after starting a project with django-admin
, it doesn't always pan out that way in practice.
django-classy-start
handles all of that neatly with classy-start
.
Your Django
project's SECRET_KEY
setting is to be kept secret in production. And things like DEBUG
and ALLOWED_HOSTS
have different values in different environments.
And it's usually not always immediately clear to n00b1es how to keep these concerns separate in their projects.
django-classy-start
addresses this problem for everyone by reading environment variables from a project-wide .env
file.
And this may be my oh, so, slight anal retentiveness speaking, but...
-
Apps started by
django-admin
contain some files which have nothing but a line of import (and a line of comment). The imports are unused and linters balk at such things. -
String literals in project and app files are delimited with single quotes. Black, the PSF-blessed Python formatter dictates that double quotes be used.
-
django-classy-start
encourages the good habit of housing test files in a tests directory.
Okay, you got me. I just wanted something relatively non-trivial to do so I can learn more about Django and improve my unit testing game.
And I found that thing in building this.
v0.0.1 (Beta) released on PyPI
Q1: Yo, @mfonism, I'm really happy for you, I'mma let you finish, but do you know you just wrote the frugly-est django-cookiecutter ever?
A1: Dude, did you read the But Really, Why? section?