Django-database-url is very nice, but AFAICT has no way to support 3rd-party 
backends. I think it needs to grow this support before it can be used in 
Django. We can adapt the backend API to help, but it's a little tricky if we 
don't want to import unused backend.

On 11 באפריל 2016 11:13:23 GMT+03:00, Marc Tamlyn <marc.tam...@gmail.com> wrote:
>I like the idea of integrating dj-database-url. There's a similar
>package
>for CACHES[0], which is a neat idea but slightly more tricky to justify
>as
>I don't know if PaaS tend to send the cache details in that format
>necessarily.
>
>I'm not sure about the rest of the mail, although I'd definitely be up
>for
>modifying the SECRET_KEY line in particular to make it strongly suggest
>that this should be different per environment.
>
>M
>
>
>[0] https://github.com/ghickman/django-cache-url
>
>On 11 April 2016 at 07:33, James Bennett <ubernost...@gmail.com> wrote:
>
>> Apologies for how late in the process this is; job hunt + moving
>> cross-country ate a lot of my time.
>>
>> At Django Under the Hood I proposed that for Django 1.10 we try to
>find
>> some common best practices for deploying Django on popular
>> platform-as-a-service (PaaS) solutions, and building support for them
>into
>> Django. The biggest one of these is probably having the ability to
>read
>> configuration from environment variables instead of hard-coding
>things into
>> settings files.
>>
>> At the very least I'd like to propose (assuming Kenneth is on board
>with
>> it) integrating dj-database-url[1] or something like it directly into
>> Django, so that there's no longer a third-party dependency for
>reading the
>> database configuration from an environment variable. Whether this is
>just
>> porting dj-database-url itself in, or making the DATABASES setting
>> understand URLs, I'm unsure of yet and would be interested to hear
>feedback
>> on. Either way I'm willing to put in the time to develop the patch.
>>
>> More generally, I'd like to see Django grow helpers for specifying
>> settings that should be read from environment variables, and which
>> environment variables to use (the email settings are another common
>case,
>> as is anything that requires an API key to access).
>>
>> There are a few ways to design this. One option would be just a
>minimal
>> wrapper around os.getenv, perhaps taking an optional type or
>type-coercing
>> function, so that it would be possible in a settings file to do:
>>
>>     SECRET_NUMBER_SETTING = env_setting('SECRET_NUMBER', int)
>>
>> However, this is not much better than the current practice of calling
>> os.getenv. A better solution might be the ability to specify a group
>of
>> settings which will be read from the environment, and have Django
>> automatically read and set them. For example:
>>
>>     ENV_SETTINGS = [
>>         ('SECRET_NUMBER_SETTING', int),
>>         ('ACME_API_KEY', str),
>>         ('VOLCANO_LAIR_PASSWORD', str),
>>     ]
>>
>> would read the named settings from those environment variables, and
>coerce
>> them to the appropriate types using the function provided.
>>
>> The main problem with this is that it's really not very elegant. But
>at
>> the moment I can't think of anything better, and so I'd like to throw
>the
>> floor open to ideas on nicer approaches to this. If one can't be
>found, I
>> do think Django 1.10 should at least figure out how to handle
>database
>> config from env since that's such a common use case nowadays, but
>ideally
>> we'd be able to pin down a good API for generically pulling
>configuration
>> from the environment.
>>
>>
>> [1] https://github.com/kennethreitz/dj-database-url
>>
>> --
>> 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/CAL13Cg85fYj0i0ysxJGo2SDesqELMeA%2BtnKJ9cdpqNHmQ%3DX3Pg%40mail.gmail.com
>>
><https://groups.google.com/d/msgid/django-developers/CAL13Cg85fYj0i0ysxJGo2SDesqELMeA%2BtnKJ9cdpqNHmQ%3DX3Pg%40mail.gmail.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/CAMwjO1Hd6JFntN49a35E-ktnXMf9pTWjisdh7fwYHC_-bbPPBA%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/62C8122A-77C0-434A-A143-23C690E511BA%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to