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.
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.
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.
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 + [...].
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.
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.
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.
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.