My take on what could be a project template for Django advanced usage, with modern tooling (for Python and UI dependencies, as well as configuration/environment management), but not too opinionated.
I rather like the directory structure change of placing the project “app” separate from the other apps, and am a big supporter of using just or task over make for a variety of reasons, but I’m going to push way back on two fronts: multiple configurations & settings files and secrets in the repo.
Your configuration & settings should be identical between environments. Otherwise you’re injecting surprises into your project that only happen in certain environments. If your local development operates differently from production, how exactly to do expect to find & fix problems that only occur in production? I wrote a whole rant on this a couple weeks ago, so my frustration on this front is rather fresh. I see it all the time and it’s always a problem I need to un-break when I start a new job. Your environment can change, but the code executing within it should not. See the 12-factor app for further discussion on this topic.
As for secrets in the repo (encrypted or not) I’ve seen this before at a previous job and while it works rather handily, I really don’t recommend it. It introduces a needless amount of complexity, can potentially leak production credentials, and requires a code change (+CI run, +deploy) to change any of the values.
Think about all the places your source code goes:
Your (likely 3rd-party external) git host
Your (also likely 3rd-party external) CI runner
Every developer’s company laptop
Potentially many developer’s personal devices when they “just want to work on that thing”
Any copies they might keep for personal reference after they quit or are fired
Any computer or phone that was used to look at the code in a browser
…and any plugins that browser might be running
Now consider how many of them likely have had access to the keys to decrypt certain values over time, how they might have stored the keys in plain text on their machine, or even been Super Careful with everything but were nonetheless compromised by a virus/hack because their kid used their computer that one time.
All that might be acceptable if the benefits were high, but they aren’t. Now, instead of just one environment to configure, you have potentially dozens: production, staging, testing, and one for every developer who’s ever worked there. Each one with different values, only some have been updated. When Steve gets fired, how many files do you have to decrypt, edit, and re-encrypt to rotate the secrets? This replaces a small headache with a migraine.
I address this in the post above as well, but the TL;DR is that you can bake known, insecure values into your project (in my case, in compose.yaml) and share any remaining actual secrets required for development sparingly via back-channels. When in staging or production, Compose isn’t in use, so your project will die unless these values are set in the environment – values which should be provided by whatever means that environment favours. Personally, I’m rather fond of tools like Secrets Manager & Vault because they offer an audit trail and a means to alter values without a code change, but a lot of companies prefer to use things like Kubernetes secrets. Whatever it is, it should not be a file in the repo.
One last note about the license: I love the GPL, but you should know that under this license, anyone using your template in their project necessarily must license that project under the GPL. Your description suggests that it’s enough to say that any modifications to the template must be shared, but that’s not how the GPL works. If I were to use your template in a project about cats, I’d be creating a “derivative work” based on your template which, under the terms of the license means my cat project must also be GPL-licensed.
What you perhaps could get away with would be treating this like documentation, and licensing it under something like the Creative Commons Attribution-ShareAlike license, where you provide it as a sort of guideline for other projects, but not as code upon which you’d base a project of your own.
I rather like the directory structure change of placing the project “app” separate from the other apps, and am a big supporter of using
justortaskovermakefor a variety of reasons, but I’m going to push way back on two fronts: multiple configurations & settings files and secrets in the repo.Your configuration & settings should be identical between environments. Otherwise you’re injecting surprises into your project that only happen in certain environments. If your local development operates differently from production, how exactly to do expect to find & fix problems that only occur in production? I wrote a whole rant on this a couple weeks ago, so my frustration on this front is rather fresh. I see it all the time and it’s always a problem I need to un-break when I start a new job. Your environment can change, but the code executing within it should not. See the 12-factor app for further discussion on this topic.
As for secrets in the repo (encrypted or not) I’ve seen this before at a previous job and while it works rather handily, I really don’t recommend it. It introduces a needless amount of complexity, can potentially leak production credentials, and requires a code change (+CI run, +deploy) to change any of the values.
Think about all the places your source code goes:
Now consider how many of them likely have had access to the keys to decrypt certain values over time, how they might have stored the keys in plain text on their machine, or even been Super Careful with everything but were nonetheless compromised by a virus/hack because their kid used their computer that one time.
All that might be acceptable if the benefits were high, but they aren’t. Now, instead of just one environment to configure, you have potentially dozens: production, staging, testing, and one for every developer who’s ever worked there. Each one with different values, only some have been updated. When Steve gets fired, how many files do you have to decrypt, edit, and re-encrypt to rotate the secrets? This replaces a small headache with a migraine.
I address this in the post above as well, but the TL;DR is that you can bake known, insecure values into your project (in my case, in
compose.yaml) and share any remaining actual secrets required for development sparingly via back-channels. When in staging or production, Compose isn’t in use, so your project will die unless these values are set in the environment – values which should be provided by whatever means that environment favours. Personally, I’m rather fond of tools like Secrets Manager & Vault because they offer an audit trail and a means to alter values without a code change, but a lot of companies prefer to use things like Kubernetes secrets. Whatever it is, it should not be a file in the repo.One last note about the license: I love the GPL, but you should know that under this license, anyone using your template in their project necessarily must license that project under the GPL. Your description suggests that it’s enough to say that any modifications to the template must be shared, but that’s not how the GPL works. If I were to use your template in a project about cats, I’d be creating a “derivative work” based on your template which, under the terms of the license means my cat project must also be GPL-licensed.
What you perhaps could get away with would be treating this like documentation, and licensing it under something like the Creative Commons Attribution-ShareAlike license, where you provide it as a sort of guideline for other projects, but not as code upon which you’d base a project of your own.