KOkolanos·Jun 23, 2022
The first two can be covered by this helpful library. [0]
[0]: https://github.com/joke2k/django-environ
In Things I do every time I start a Django projectjoke2k
django-environ
Python2019–2022
joke2k / django-environ
django-environ
Django-environ allows you to utilize 12factor inspired environment variables to configure your Django application.
5Distinct people
6Mentions
0Explicit recommenders
3.2KGitHub stars
What to know before exploring
What it is
Django-environ allows you to utilize 12factor inspired environment variables to configure your Django application.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year6 dated mentions
Observed mentions: 2019-09-09 20:18:32 UTC to 2022-06-23 23:30:56 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
6 sources`django-environ` makes a fairly simple effort[1] to strip starting/ending quotes off of literals. This will set the value of MY_VAR to the string `foo` (with doublequotes removed) in django-environ:
MY_VAR="foo"
Docker does not do any quote parsing. For this same env file, it will set the value of the variable to `"foo"` (retaining the doublequotes in the value).
Bash, of course, requires quotes if the variable contains any special bash characters (for example, literal JSON with curly brackets), but its quote handling is much more complex. django-environ doesn't interpret bash code; it just does simple quote chomping.
There's no reliable .env syntax you can use that works in all 3 of django-environ, Docker, and bash; and any variable that should start and end with quotes that are not stripped off can't be expressed in a way that bo
Read the rest
th Docker and django-environ will read in the same way.
This may seem like a nit-picking edge case, but it's indicative of the design philosophy in django-environ of trying to be "helpful", but in ways which lead to subtle confusion. The way it guesses the path to your `.env` file is another example.
[1] https://github.com/joke2k/django-environ/blob/main/environ/e...
The community writ large is already using django-environ to solve the problems you faced.
https://github.com/joke2k/django-environ
In A guide to organizing settings in DjangoThis isn't wrong advice but their tone of authority seems a bit misplaced.
1. Make settings.py a package
2. Please do not put anything more than imports in __init__.py since you are adding logic downstream.
3. Use django environ https://github.com/joke2k/django-environ which gives you a defined schema of your environment needs with casting and default values when needed.
Now you keep your .env files, keep your setting overrides (settings/base.py, settings/local.py, etc) when needed AND you have defined a schema with non-string types for your environment variables.
From the readme you can see how you make a schema with a casted type and default value:
env = environ.Env(
DEBUG=(bool, False)
)
In A guide to organizing settings in DjangoPackage it; as a container or as containers that install a RPM/DEB/APK/Condapkg/Pythonpkg (possibly containing a zipapp). Zipapps are fast.
If you have any non-python dependencies, a Pythonpkg only solves for part of the packaging needs.
Producing a packaged artifact should be easy and part of your CI build script.
Here's the cookiecutter-django production docker-compose.yml with containers for django, celery, postgres, redis, and traefik as a load balancer:
https://github.com/pydanny/cookiecutter-django/blob/master/%...
Cookiecutter-django also includes a Procfile.
With k8s, you have an ingress (~load balancer + SSL termination proxy) other than traefik.
You can generate k8s YML from docker-compose.yml with Kompose.
I just found this which describes using GitLab CI with Helm:
https://davidmburke.com/2020/01/24/deploy-django-with-helm-t.
Read the rest
..
What is the command to scale up or down? Do you need a geodistributed setup (on multiple providers' clouds)? Who has those credentials and experience?
How do you do red/green or rolling deployments?
Can you run tests in a copy of production?
Can you deploy when the tests that run on git commit pass?
What runs the database migrations in production; while users are using the site?
If something deletes the whole production setup or the bus factor is 1, how long does it take to redeploy from zero; and how much manual work does it take?
CI + Ansible + Terraform + Kubernetes.
Whatever tools you settle on, django-eviron for a 12 Factor App may be advisable.
https://github.com/joke2k/django-environ
The Twelve-Factor App:
https://12factor.net/
For me, I prefer Django, but I haven't used Rails in a number of years. In general I prefer Python over Ruby because it's more explicit and less magic, but Ruby definitely has its conveniences.
That being said, I am not a Ruby developer, I am a Python developer, so I'll try to address these points as best I can from the other side of the equation.
* Authentication - this is fairly simple to address. It's a fairly easy-to-use pluggable backend. It's not very hard to write a system to replace the default which would let you log in using other credentials. Also, a few years ago you couldn't replace the default User model - that has since been changed.
* Asset pipeline - fair point, but I prefer to keep my assets separate from the backend if possible - my current work project has a backend API in django with a separate frontend repo with all
Read the rest
the JS/CSS
* Configuration - the best solution for this I've found is django-environ[0]. Alternatively, the built-in `DJANGO_SETTINGS_FILE` environment variable lets you specify a different base config file.
* Sidekiq/Celery - The API, I'll give you, however it's fairly easy to configure Celery to use Redis
* Mailer previews - I've used mailhog[1] before. This gives you a local mailbox to test with and will be closer to your final configuration anyway.
* Better security - possibly by default, but I haven't had any issues with django-rest-framework in the past
* Testing - pytest with pytest-django is also great to work with.
* Django ORM vs ActiveRecord - I don't have a ton of experience with ActiveRecord but I like the Django ORM. There's also SQLAlchemy, but it's a bit odd to rip that out of django if you don't need to.
I like Django because it's solid out of the box, but still provides a way to extend the core to be as flexible as you want. I assume it's possible to do this with Rails, but that's not my area of expertise.
I do appreciate you outlining things you like better as opposed to just saying "Django is terrible". I'll definitely have to try Rails again and see what I think of it now.
[0] https://github.com/joke2k/django-environ
[1] https://github.com/mailhog/MailHog