Suggestion to restructure conf package and remove envparse

[benjaoming]

Hi @keimlink

Thanks for the project :) I learned a lot, and I really like it!

I know that I can just go and create my own flavor, but maybe it would be much more fun to discuss the approaches, and if you like, I don't mind adding a PR.

I would consider the template for the following purpose:

To bootstrap a simple and easily readable Django project based on best practices, avoiding patterns that some larger quantity of users would want to refactor afterwards.

I would consider the following:

1) Remove envparse. My own reason is that it entangles development and production settings. I would much prefer to have settings.development and settings.production (possibly add settings.local to the .gitignore template). This way, settings become a lot easier to read and overwrite. The manage.py script has the --settings option, making it easy to switch between settings.

2) Move urls and wsgi up a level, for me they are not "configuration" any more than the whole project is then a configuration of sorts.

3) Rename conf to settings.

Here is a pattern that is quite similar to what I mean:

https://django-best-practices.readthedocs.io/en/latest/projects.html#handling-urlconfs-for-multiple-environments

I was once writing a project where we actually included the bootstrapping of settings.local in our manage.py, such that new users couldn't avoid having it created when it didn't exist and then seeing that it existed and contained their secrets.

[keimlink]

Hi Benjamin,

thank you for your feedback, it's highly appreciated!

Actually one of the reasons to create the template and publish it was to be able to discuss it with others.

History and Motivation

Maybe some information why I created this template is useful to understand some decisions.

Before creating this project template I created transcode-de/cookiecutter-django-project together with my team at @transcode-de. The goal was to create a template that was following best practices we were using in our daily work.

Unfortunately it turned out that maintaining such a huge template requires a lot of time and background knowledge. The situation got worse when wanted to introduce a new asset pipeline.

In the end it was too time consuming to maintain the template.

So one of the decisions I made when creating this template was to keep out parts like asset pipeline, continuous integration or deployment.

By keeping this new template as small and simple as possible I hope it will be easier to maintain it in the long run.

Your motivation to use the template resonates with my motivation:

To bootstrap a simple and easily readable Django project based on best practices, avoiding patterns that some larger quantity of users would want to refactor afterwards.

"simple and easily readable" as well as "avoiding patterns that some larger quantity of users would want to refactor" are the most important parts for me.

Replies to Your Suggestions

1. We tried using different Python modules for different sets of settings. Usually this infamous pattern is being used somewhere in the module:

   try:
       from other_settings import *
   except ImportError:
       pass

   With this pattern one usually gets very soon into problems.

   One possible problem are settings that need to be evaluated to define another setting. This is because every settings module is evaluated from top to bottom.

   Modularisation of settings into smaller, independent domain specific modules is very hard to accomplish.

   Furthermore I'm a big fan of the twelve-factor methodology, especially it's idea to store configuration.

   This is why envparse has been added to the template as the smallest common dominator. Starlette, a brand new ASGI framework, also uses this methodology for it's configuration.

   You could say that settings in this approach provide defaults which can always be overwritten by an environment variable.

   So local development settings are also mainting as a set of environment variables.

   But my favorite solution is django-configurations.

   Unfortunately I hadn't the time to add it to the template in way that it would be usable for others.

   And django-configurations still has a way to address different Django settings by loading different classes.

2. Moving the wsgi module one level up sounds like a great idea. :+1: It's actually a script to start the WSGI app.

   But I wouldn't move the urls module. Why? The Django documentation has the answer:

   To design URLs for an app, you create a Python module informally called a URLconf (URL configuration).

   A urls module is also configuration.

3. If urls are kept in the conf package it should not be renamed to settings.

Action Items

These are the action items I would take from your proposal:

1. Describe motivation for the project in README.md, especially why it's so slim and the influence of the twelve-factor methodology.
2. Explain how to contribute in README.md.
3. Move the wsgi module on level up.

I hope I could explain my motivation while also addressing your ideas!