5 ms·

Show HN: importd – d is for django

116 points by amitu 14y ago

neostar20 14y ago
Awesome
ranedk 14y ago
This is pretty cool. Makes stuff much more manageable.
samwillis 14y ago
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.
- 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.
robertfw 14y ago
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/ http://flask.pocoo.org/
- signed0 14y ago
  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?
amitu 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
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.
IgorPartola 14y ago
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 14y ago
  Hey Igor, if you take a look at http://pythonhosted.org/importd/#importd-and-custom-models 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 14y ago
    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.
_neil 14y ago
The 'jango' is silent? I'll see myself out.
- VuongN 14y ago
  I shamelessly enjoyed this.
davidwtbuxton 14y ago
Related: django-mini, a command-line tool for running Django management commands without a full settings.py. https://github.com/davidwtbuxton/django-mini https://github.com/davidwtbuxton/django-mini I wrote it to make it easier to run tests for plug-able Django apps.
tlarkworthy 14y ago
What kind of sorcery is this?
dgulino 14y ago
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.
benjamincburns 14y ago
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.

116 points by amitu 14y ago

neostar20 14y ago

Awesome

ranedk 14y ago

This is pretty cool. Makes stuff much more manageable.

samwillis 14y ago

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

robertfw 14y ago

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/ http://flask.pocoo.org/

signed0 14y ago
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?

amitu 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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 14y ago

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.

IgorPartola 14y ago

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 14y ago
Hey Igor, if you take a look at http://pythonhosted.org/importd/#importd-and-custom-models 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 14y ago
  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.

_neil 14y ago

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

VuongN 14y ago
I shamelessly enjoyed this.

davidwtbuxton 14y ago

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

tlarkworthy 14y ago

What kind of sorcery is this?

dgulino 14y ago

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.

benjamincburns 14y ago

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.