Hi Tom,
Great to hear – no rush if you’re busy with other things. Here’s a quick
proof of concept, with 20 different pages/scenarios, tested with Axe, HTML
Code Sniffer, and Lighthouse:
https://github.com/thibaudcolas/django_admin_tests.
I’m not a big fan of Lighthouse personally, and I
This makes sense, I have a project that has a lot of settings files that
get activated depending on the value of DJANGO_SETTINGS_MODULE. The
solution i outlined above takes your reservations under consideration, if
you want to use it, great, if not also great -- its a supplement not a
Those are valid concerns, and I want to especially come back to "all of
this has to be optional, which seems to rule out making it part of the
starting project template".
But first, I want to reiterate that what's vital to me (and this may be
only my concern, of course!) is that newer developers,
tMost of the world is not as seamless as heroku. My DevOps won't give me
any more than a handful of environment variables. I wanted something like
DATABASE_URL, but all I have is DJANGO_LOG_DIR and DJANGO_SETTINGS_MODULE,
and so I need many, many settings files. I think that happens a lot, and
Carlton—thanks very much for the feedback. Javier—likewise. In particular,
the imagined API you describe above is very appealing to me: start with
`from_env` and then if you learn more about this and want to, add in some
`EnvFileLoader`.
I want to make clear my motivation and agenda here: I have
I looked at the libs that do what we want:
django-configurations - it looks like they use environment variables /
either via loading them from the environ or a key/value pair file. Having
classes inside the settings.py might be weird to people.. at the least very
different.
confucius - very
There are plenty of project templates out there that offer more
fully-featured starting points. It's generally agreed that's out-of-scope
for the provided startproject template.
But could we make it easier to use environment variables in the default
template? That seems like a reasonable
A quick update first. I'm pretty busy with a combination of day job and
personal projects, but I should have time to start writing the draft DEP in
the next week or two.
Thibaud, I think the absolute most important thing is a way to measure
progress, even if - as others have mentioned - that
Week ending June 21, 2020.
Released Django 3.1b1.
*Triaged:*
https://code.djangoproject.com/ticket/31707 - django-ldap-auth-backend
(invalid)
https://code.djangoproject.com/ticket/31702 - Support operator classes for
unique indexes on PostgreSQL. (accepted)
