Show HN: importd – d is for django | Hacker News Reader

Show HN: importd – d is for django

pythonhosted.org

116 pointsamitu30 comments

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

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

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.

Hey, I am the author of the module, as well as that of smarturls and fhurl mentioned there.
I understand the concern about magic, and moving parts. I guess the right answer to that concern would be unittests, that I am in the process or writing.
I hope you enjoy the module as much as I do :-)

Would you mind explaining the use cases where this could be better than standard django? (or the ones that motivated you to develop it)
I think it is really interesting, but cant find a good example where I should use it

Hey singold,
The primary motivation was when making it easy to use django for API like apps. Moving to flask etc meant losing all the django knowledge and batteries. Most simple project start small, and importd makes it easy for starting small, yet importd intends to remain completely compatible with django.
importd already can play nicely with rest of django ecosystem, and I am trying to figure out what more I can do to make that easier.

Thanks! I really like django, and I think this could be a good way to introduce someone to django's concepts too.
I'll be trying it out soon :)

This is a great tool for API prototyping and testing.
However, I wouldn't use it for a full-blown app. It's like using Flask. You could do it in a single file, but it rarely makes sense to do so. By the time you organize your code, you end up with a basic MVC app structure anyway.
Relocateable by default is nice. But it's pretty simple in Django to design your settings file to be path-relative.

Related: django-mini, a command-line tool for running Django management commands without a full settings.py.
https://github.com/davidwtbuxton/django-mini
I wrote it to make it easier to run tests for plug-able Django apps.

The 'jango' is silent? I'll see myself out.

I shamelessly enjoyed this.

the resulting view ends up looking at lot like it would in flask [1]. I would be worried about the number of moving parts that are in play.
[1] http://flask.pocoo.org/

That was my take as well. Why would someone want to use this when there already exist minimalist python web-servers such as flask & bottle that do not require magic?

So this is really cool to get started with, but I would worry that when you need to start taking advantage of various abstractions that Django provides, you'd end up having to do a huge refactor. Not that Django's abstractions are perfect, but if your app starts out living in a single file, you are more likely than not going to need to do some modularization at some point.

Hey Igor, if you take a look at http://pythonhosted.org/importd/#importd-and-custom-models, you will see that importd still works perfectly well with normal django app, and it is recommended when your project grow large that you indeed split your project into apps for maximum modularity and reusability.
importd makes it easy to start using django for simple couple of pages/api apps, and it remains compatible with rest of django, that is the goal.

Yup, I saw that on the first pass. So you have the ability to refactor, but you are basically guaranteeing that you will need to if your app grows beyond the couple of pages/api's size.
Additionally, there's another thing that importd side-steps: now there is no more settings.py. While I understand why, there is a reason for it to exist: configuration and code do not always mix. Sometimes you need a dev key and a prod key; sometimes you need different IP addresses set in different config files and you cannot autodiscover them (e.g.: they are not addresses from the same box). Having a better settings.py would go a long way towards solving this as compared to eliminating it altogether.

As others have said, this looks really useful for proof of concept/prototyping work. The first use case that came to mind was hackathons, actually.
It'd be really nice if there was a fast, automated way to "unwrap" the microframework version of your webapp into the full-blown django project so that you can start hardening things for production in a single command.

This is pretty cool. Makes stuff much more manageable.

fyi: This requires django 1.4. I ran w/1.3.1 and got this error when running the helloworld example:
ImportError: No module named wsgi
I updated to 1.4.5 and it worked fine.

What kind of sorcery is this?

Reply on news.ycombinator.com