Re: Making Django more PaaS-friendly

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

Re: Making Django more PaaS-friendly

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`,

Re: Making Django more PaaS-friendly

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.

Re: Making Django more PaaS-friendly

> 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.

Re: Making Django more PaaS-friendly

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

Re: is_authenticated as property

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

Re: is_authenticated as property

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

Re: Making Django more PaaS-friendly

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

Re: Making Django more PaaS-friendly

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

Re: Making Django more PaaS-friendly

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

Re: Django template 'if ... is' feature design

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

Re: Making Django more PaaS-friendly

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

Re: Making Django more PaaS-friendly

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

Re: Making Django more PaaS-friendly

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

Re: Making Django more PaaS-friendly

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

Re: Making Django more PaaS-friendly

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

Re: Making Django more PaaS-friendly

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

Making Django more PaaS-friendly

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