5 ms·

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

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://simonwillison.net/2009/May/19/djng/ http://news.ycombinator.com/item?id=615891 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 https://github.com/simonw/djng

mattdeboard 14y ago
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.
StavrosK 14y ago
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.
teilo 14y ago
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.
- misiti3780 14y ago
  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.
  - singold 14y ago
    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
    - misiti3780 14y ago
      something like this: http://tech.yipit.com/2011/11/02/django-settings-what-to-do-about-settings-py/ http://tech.yipit.com/2011/11/02/django-settings-what-to-do-...
  - natrius 14y ago
    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 + [...].
    - antihero 14y ago
      This so much. You should be setting DJANGO_SETTINGS_MODULE in your uwsgi config or in your virtualenv postactivate for dev.
  - antihero 14y ago
    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
  - teilo 14y ago
niix 14y ago
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.

mattdeboard 14y ago

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.

StavrosK 14y ago

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.

teilo 14y ago

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.

misiti3780 14y ago
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.
- singold 14y ago
  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
  - misiti3780 14y ago
    something like this: http://tech.yipit.com/2011/11/02/django-settings-what-to-do-about-settings-py/ http://tech.yipit.com/2011/11/02/django-settings-what-to-do-...
- natrius 14y ago
  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 + [...].
  - antihero 14y ago
    This so much. You should be setting DJANGO_SETTINGS_MODULE in your uwsgi config or in your virtualenv postactivate for dev.
- antihero 14y ago
  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
- teilo 14y ago

niix 14y ago

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.