My django-classy-settings also supports env-based settings, in a
declarative manner with defaults.
What I've yet to crack (though the discussion is underway) is good
formats for structured settings like caches and databases.
Generally I use dj-database-url for my own projects :)
I like the idea of having it scan INSTALLED_APPS to allow registering
custom DB backend protocols... though I think the modern approach is
AppConfig.ready ?
--
Curtis
On 29/05/17 08:23, li...@lew21.net wrote:
There's also https://github.com/doismellburning/django12factor - and it
simplifies all the boilerplate, that is still required in
django-environ, into:
import django12factor
globals().update(django12factor.factorise())
It would be quite nice if Django supported 12factor configuration
natively, or at least with a single function call like this one.
Regards,
Linus
On Sunday, May 28, 2017 at 12:09:57 AM UTC+2, Tim Allen wrote:
I've recently been introduced to `django-environ`, a similar library
that has additional features to DB connect URLs that we may want to
consider: https://github.com/joke2k/django-environ
<https://github.com/joke2k/django-environ>
It has the same issue with third party DB engines; for example, I
recently issued a PR to include `pyodbc` as an option. It has some
nice newcomer friendly features, such as a cleaner way of
determining BASE_URL / SITE_ROOT. Have a look at the URL for a good
"before" and "after" settings file example.
Having full support for .env files would make Django projects easier
to bring in line with 12-factor.
Regards,
Tim
On Saturday, May 27, 2017 at 3:52:23 PM UTC-4, Tom Forbes wrote:
Edit: DJANGO_SETTINGS_MODULE isn't relative, it will import any
arbitrary module you give it. If we accept that then I think we
are accepting the risk of imports via an attacker controlling
environment variables whilst Django starts up?
On Sat, May 27, 2017 at 8:49 PM, Tom Forbes <t...@tomforb.es> wrote:
> I'm wary of possible security ramifications: if we do this,
changing a
configuration value will import an arbitrary module, which
could make it easier to run arbitrary code in some
scenarios. I don't have a clear threat model in mind here,
though.
Good point, it's not wise to enable this even without a
clear threat model. Django does import the settings based on
an environment variable, but it's relative and if you can
use that to do anything nasty then you're most likely
already through the airtight hatch (so to speak). However
importing potentially global modules could be bad news.
Ignoring it is always an option, but could we not specify
that the third party database provider has to be in the
`INSTALLED_APPS`? That could provide some form of
whitelisting so not any old module is imported. Not sure
about any issues that may arise from this though.
> One possibility would be to use entrypoints in setuptools, this
way 3rd party backends could specify a name which then has a
fixed & verified import path.
This seems like it could get complex, and be quite unlike
anything else in Django.
Perhaps just supporting this for first-party database
backends is easiest?
On Thu, May 25, 2017 at 8:46 AM, Aymeric Augustin
<aymeric....@polytechnique.org> wrote:
Hello,
I'm wondering what the exact definition of the URL
format is. Is it specified somewhere? Or is it just:
[engine]://[username]:[password]@[host]:[port]/[name]
where we create arbitrary [engine] values in an ad-hoc
fashion?
On 24 May 2017, at 21:21, Tom Forbes <t...@tomforb.es>
wrote:
My two cents: connection strings/database URI's are a
feature I've sorely missed in Django.
Built-in functionality to convert environment
variables like DJANGO_DB_DEFAULT (or more generally
DJANGO_DB_*key*) into the relevant DATABASE setting
would make some deployment situations a lot simpler.
Currently, unless you use dj-database-uri you have to
define a bunch of ad-hoc DB_USER/DB_PASSWORD etc env
variables and price the dictionary together yourself.
Fully agreed. While relatively minor, it's an annoyance.
How does this library complex keys like OPTIONS, TEST
or DEPENDENCIES?
I don't think it's reasonable to cram them in a URL.
dj-database-url allows passing options as extra keyword
arguments. Other values should be explicitly added in
the settings module, by updating the dict generated from
the URL.
To help support third part backends: perhaps the
scheme portion of the URI could be either a relative
import from django.db.backends or an absolute import
to a third party library? It seems URI schemes can
have dots and underscores in them, so they can be
python package paths.
I.e sqlite3://xyz would resolve go
django.db.backends.sqlite3, but sqlserver_ado://xyz
would resolve to the third party django-mssql engine
via an absolute import.
I'm wary of possible security ramifications: if we do
this, changing a configuration value will import an
arbitrary module, which could make it easier to run
arbitrary code in some scenarios. I don't have a clear
threat model in mind here, though.
I'd rather specify the database engine explicitly when
calling dj-database-url if it's a third-party engine.
There's an open question about what to do with the
[engine] part of the URL in that case. Ignoring it
entirely is the easiest.
Best regards,
--
Aymeric.
--
You received this message because you are subscribed to
the Google Groups "Django developers (Contributions to
Django itself)" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to
django-develop...@googlegroups.com.
To post to this group, send email to
django-d...@googlegroups.com.
Visit this group at
https://groups.google.com/group/django-developers
<https://groups.google.com/group/django-developers>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/A0870D90-75DE-496B-A838-AC7D7488A67D%40polytechnique.org
<https://groups.google.com/d/msgid/django-developers/A0870D90-75DE-496B-A838-AC7D7488A67D%40polytechnique.org?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to django-developers@googlegroups.com
<mailto:django-developers@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/69f0a647-42cf-4ef6-9ad7-bbe5e8fa779b%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/69f0a647-42cf-4ef6-9ad7-bbe5e8fa779b%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/da76c374-083d-4e6d-f826-14407b4c0ad9%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.
