Hacker News Reader

Comment by samwillis | Hacker News Reader

This is good although I think it has a little to much magic for me. Everything seems to happen just by using different arguments to the 'd' function, even the settings. I think its a good idea though! It would be awesome if Django had a built in way of doing single file apps.

Simon Willison (one of the Django core devs) made a Django micro framework a few years ago, I don't think its been developed much recently though.

http://simonwillison.net/2009/May/19/djng/

http://news.ycombinator.com/item?id=615891

EDIT:

Simons website seems to be down, an overview of Djing is here: https://github.com/simonw/djng

View on HN

I agree with you, but I think the use case is "that small, 3-template page I want as a quick interface", and this fits the use case perfectly. It usually takes quite a bit of time to set up a Django project (with all the boilerplate), and something like this makes it much, much faster.

Two thumbs up, from me.

I like the Services idea. Django's settings file is the weakest link in the framework. It's easy to roll your own settings apps if all you need to configure is your own code. But that just makes things more complicated when you are integrating other apps.

I've tried a few different apps designed to move settings into the database. None of them have worked very well. This area of Django is still ripe for some killer app to become a defacto standard.

why not just use multiple layered settings files?

in .... settings.py put

from local_settings.py import *

at the bottom

then have

local_settings.dev.py local_settings.prod.py local_settings.release.py

that you copy to local_settings.py depending on the situation.

Or better, have a folder called local_settings with an __init__.py empty file in (making it a package) and then just drop your custom settings there

something like this:

http://tech.yipit.com/2011/11/02/django-settings-what-to-do-...

It's less painful if you invert those files. For example, create settings/defaults.py, then in settings/dev.py, import * from defaults and override what you need to. Set DJANGO_SETTINGS_MODULE appropriately. You'll thank me when you're adding dev-only apps, middlewares, etc. and can say INSTALLED_APPS = INSTALLED_APPS + [...].

This so much. You should be setting DJANGO_SETTINGS_MODULE in your uwsgi config or in your virtualenv postactivate for dev.

Don't do this, do:

* settings/base.py * settings/production.py * settings/local.py

settings/base would have your "common" settings, settings/local.py could be as simple as from .settings.base import

I already do that. I have a common_settings.py, a dev_settings.py, and a local_settings.py. That's not really the use case I am speaking of.
First, it still makes you put all application config into a single config file (considering that even if you "inherit" settings from a common file, it's 100% equivalent to having one big settings file).
Second, you cannot change these settings in-app. They are hard-coded.

If it's not already supported, it shouldn't be difficult to make a Django process respond to the HUP signal by reloading it's settings. That's how Postgres does it.

Took the comment right out of my brain. Looks cool and very novel, bound to be an incredibly leaky abstraction though. Doesn't take away from the novelty/coolness though.

I agree. Great idea in all but Django already is so batteries included, I don't think we need to take it down even further from what it is.

Reply on news.ycombinator.com