Re: Making Django more PaaS-friendly

On Tue, May 10, 2016 at 1:48 AM, Carl Meyer wrote: > Hi Anssi, > > On 05/09/2016 06:53 AM, Anssi Kääriäinen wrote: > I'm curious to hear more about this - could you give some example DEPs > where this was a problem? In the case of the two DEPs I was most closely > involved with

Re: Making Django more PaaS-friendly

Hi Anssi, On 05/09/2016 06:53 AM, Anssi Kääriäinen wrote: > I'm very much afraid we are in a situation where we have a documented > DEP process which isn't actually enforced, nor does it document what > we actually do. > > Python's PEP process is useful as the document evolves while the > design

Re: Making Django more PaaS-friendly

I'm very much afraid we are in a situation where we have a documented DEP process which isn't actually enforced, nor does it document what we actually do. Python's PEP process is useful as the document evolves while the design evolves. What we do with DEPs is different, we first design something,

Re: Making Django more PaaS-friendly

On Monday 09 May 2016 05:06:47 James Bennett wrote: > Whee, this thread got big! > > The takeaway I'm getting here is that we should be careful about what we > adopt into core and when; I'm going to take a couple days and write up some > notes on what I think a good conservative approach would

Re: Making Django more PaaS-friendly

Whee, this thread got big! The takeaway I'm getting here is that we should be careful about what we adopt into core and when; I'm going to take a couple days and write up some notes on what I think a good conservative approach would look like, and ask for feedback on that. (spoiler: probably the

Re: Making Django more PaaS-friendly

Hi Marcin, On 04/26/2016 08:12 PM, Marcin Nowak wrote: > But I would like to say my thoughts about "settings" itself. > They were good (simple) before incuding nested dictionaries. > After switching to dicts the settings handling went harder way. I agree that settings grouped into dicts are

Re: Making Django more PaaS-friendly

Hello, If anything, this discussion shows that people have come up with a wide variety of customized solutions to meet their use cases. That supports Django’s historical decision not to be too prescriptive in this area. I still think James’ proposal is valuable because it will nudge developers

Re: Making Django more PaaS-friendly

Hi all, On Wednesday, April 13, 2016 at 9:58:18 PM UTC+2, Carl Meyer wrote: > > Hi James et al, > > In general, I like the idea of adding a helper to Django to read > settings from the environment. I think this helper should be kept as > simple and non-magical as is reasonable. Thus: > > This

Re: Making Django more PaaS-friendly

On 12 April 2016 at 05:35, Martin Owens wrote: > There is a difference between settings intended by developers to be used by > other developers /../ And settings used by systems administrators to define > the environment they are deployed to as well as any deployment specific

Re: Making Django more PaaS-friendly

We deploy django use AWS Elastic Beanstalk and use credstash for secrets: https://github.com/fugue/credstash So we can just do PASSWORD = credstash.getSecret('password') which works pretty well with the AWS Key Management Service. What is a pain is that the AWS Health Check does not set the

Re: Making Django more PaaS-friendly

On 11 April 2016 at 07:33, James Bennett wrote: > 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

Re: Making Django more PaaS-friendly

On 14/04/16 05:57, Carl Meyer wrote: Hi James et al, In general, I like the idea of adding a helper to Django to read settings from the environment. I think this helper should be kept as simple and non-magical as is reasonable. Thus: - I'm in favor of a flexible helper function that can be

Re: Making Django more PaaS-friendly

Hi James et al, In general, I like the idea of adding a helper to Django to read settings from the environment. I think this helper should be kept as simple and non-magical as is reasonable. Thus: - I'm in favor of a flexible helper function that can be manually used in a settings file to read

Re: Making Django more PaaS-friendly

I like the try to move things towards this kind of settings more PaaS-friendly. As a Django user, I'd like to see 'DSN' or 'URL' for the database as a built-in in Django. I don't mind setting it in the dict as so: ``` DATABASES = { 'default': { 'DSN':

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