Hacker Newsnew | comments | show | ask | jobs | submitlogin
Show HN: importd – d is for django (pythonhosted.org)
110 points by amitu 507 days ago | comments


samwillis 507 days ago | link

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

-----

StavrosK 507 days ago | link

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 507 days ago | link

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 507 days ago | link

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.

-----

natrius 507 days ago | link

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 507 days ago | link

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

-----

teilo 507 days ago | link

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.

-----

mvc 507 days ago | link

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.

-----

antihero 507 days ago | link

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

-----

singold 507 days ago | link

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 507 days ago | link

something like this:

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

-----

mattdeboard 507 days ago | link

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.

-----

niix 507 days ago | link

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.

-----

amitu 507 days ago | link

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

-----

singold 507 days ago | link

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

-----

amitu 507 days ago | link

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.

-----

singold 506 days ago | link

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

-----

teilo 507 days ago | link

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.

-----

davidwtbuxton 507 days ago | link

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.

-----

_neil 507 days ago | link

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

-----

VuongN 507 days ago | link

I shamelessly enjoyed this.

-----

robertfw 507 days ago | link

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/

-----

signed0 507 days ago | link

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?

-----

IgorPartola 507 days ago | link

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.

-----

amitu 507 days ago | link

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.

-----

IgorPartola 507 days ago | link

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.

-----

benjamincburns 507 days ago | link

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.

-----

ranedk 507 days ago | link

This is pretty cool. Makes stuff much more manageable.

-----

dgulino 507 days ago | link

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.

-----

tlarkworthy 507 days ago | link

What kind of sorcery is this?

-----




Guidelines | FAQ | Lists | Bookmarklet | DMCA | News News | Bugs and Feature Requests | Y Combinator | Apply | Library | Contact

Search: