I look after many different django websites and I'd like to add something
conceptual.
There is a difference between settings intended by developers to be used by
other developers in order to enable and configure their app's behaviour so
it work with other code. (I call these developer settings)
Just to throw another voice in here, I'm currently using django-environ[1],
as mentioned by Sean Brant. In addition, I'm using a settings setup based
on cookiecutter-django[2]. This means having my settings split into
`config.settings.common`, `config.settings.local`,
`config.settings.production`,
On 12/04/16 04:26, Aymeric Augustin wrote:
On 11 Apr 2016, at 19:39, Curtis Maloney wrote:
1. All env vars can have a fallback value (the method in my case)
2. You can mark an env var as not having a fallback value, and it will raise an
error at start up if not set.
There’s an additional com
> On 11 Apr 2016, at 19:39, Curtis Maloney wrote:
>
> 1. All env vars can have a fallback value (the method in my case)
> 2. You can mark an env var as not having a fallback value, and it will raise
> an error at start up if not set.
There’s an additional complexity here.
Usually, it’s best fo
Just want to throw my 3c in here...
Firstly, for reference, I wrote django-classy-settings to help with
various settings related problems, one of which being env-based setting.
https://github.com/funkybob/django-classy-settings
As my env decorators are written to be class properties, they don
On Monday, April 11, 2016 at 6:57:46 PM UTC+2, Tim Graham wrote:
>
> I cannot think of much we could do besides monkey-patching the custom-user
> model.
>
I would not call checking and rewriting the class in __new__
monkey-patching, but…
--
You received this message because you are subscribe
Florian has raised the issue of custom user models which define these
methods, "Allowing custom user models to have a method is a security risk
since all checks will now return true." I proposed a compatibility system
check error to detect that situation to alert the user. Do you think the
back
https://github.com/joke2k/django-environ has helpers for loading most of
the backends from urls. We use it with a docker based deployment at the
moment.
On Mon, Apr 11, 2016 at 8:46 AM, Ryan Hiebert wrote:
> I'd love to see better support for PaaS configuration, especially
> 12-factor. We use He
I'd love to see better support for PaaS configuration, especially 12-factor. We
use Heroku, and I've been directly exposed to the challenges and had to come up
with some of my own solutions. Here's some thoughts I have on the matter, in no
particular order.
The SECRET_KEY needs to _not_ be req
Very very glad to hear this. All too frequently in #django, "please show us
your settings (and remove any sensitive data)" ends up with a "Now you need
to reset your SECRET_KEY" etc.
I wrote django12factor to do something similar. One of the things I like
least about it is the process of actual
On 08/04/16 01:40, Stephen Kelly wrote:
> Carl Meyer wrote:
>
>> It might be worth adding a short documentation note. We largely want to
>> avoid documenting Python's behavior in the Django docs, but a short note
>> in the template `is` docs reminding people not to ever use `is` with
>> strings or
Hi James,
>From the experience on our projects, the ``CONFIG.getstr('db.password')``
>format works well in settings files:
- It makes it clear that this field is loaded from the environment, and what
type is expected
- The setting is set and loaded in the same place
- It allows for type checking
Here is some past work on "Minimize the risk of SECRET_KEY leaks" [0] that
was never completed: https://github.com/django/django/pull/2714
[0] https://code.djangoproject.com/ticket/20081
On Monday, April 11, 2016 at 6:51:38 AM UTC-4, Josh Smeaton wrote:
>
> I kind of like the idea of making all
I kind of like the idea of making all settings configurable via the
environment by prefixing with DJANGO_SETTINGNAME. Sort of like how click
allows environment variables for
options: http://click.pocoo.org/5/options/#values-from-environment-variables.
Ideally configuring settings from the envir
We have a chicken’n’egg problem to support third party database backends with
dj-database-url’s current API:
- It is each backend’s responsibility to parse the URL and extract the
configuration for a given database.
- Parsing the URL is a prerequisite to figure which database backend to pick
fo
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+
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 u
17 matches
Mail list logo
