7 ms·

What’s your favorite Django app?

42 points by niels 16y ago

marcc 16y ago
I don't know... Schema migration is rare and something I want complete control over while the debug toolbar is something I use constantly. I definitely would have submitted a vote for the toolbar.
- StavrosK 16y ago
  Schema migration is something I definitely want done right, otherwise production will break. If South didn't exist, I would think long and hard about adding a field, and I'd have to make changes manually in the database, in an error-prone and non-repeatable manner. In short, you use DjDT more often, but South is by far a much more important part. Which one could you live without, South or DjDT? I know which one I'd pick...
stuartk 16y ago
I still believe South should be included in Django itself, but the South devs wanted to keep it as a separate app. I remember when I first started learning Django. You follow the tutorial, write your models. Then you start playing about and want to add an extra field to a model and....oh wait, I need to either add it manually to the database or use a 3rd party app to do it. To my mind it's part of the workflow as you build an app.
- endlessvoid94 16y ago
  Agreed. This is one nice thing about rails, the migrations are part of the framework.
- po 16y ago
  It is definitely part of the workflow. I don't see how having it separate makes it any less of a part of your workflow. Git is also a part of my workflow. No harm in having it be separate. The advantage to keeping it separate is it allows South to release on it's own faster schedule. It gets features much quicker than the base framework. I imagine it will get rolled in some day, when the feature set stabilizes a bit.
  - stuartk 16y ago
    Good point in regards to a faster release schedule for South. And yes, it is part of my workflow. But for a new Django developer, it's not obvious, as it's not part of the documentation.
    - po 16y ago
      The fact that it's not obvious is also a good point. I recently brought up the documentation issue on the mailing list and received a pretty encouraging response from Mr. Kaplan-Moss himself: http://groups.google.com/group/django-developers/browse_thread/thread/6e810d18249c2792 http://groups.google.com/group/django-developers/browse_thre... Django 1.3 is a tightening of the bolts release so I am going through and updating where improvements are needed and patching where I feel capable. Perhaps you or others would like to improve the documentation as well?
      - levigross 16y ago
        I hope they start to use a DVCS to kickstart the development.
    - andybak 16y ago
      The solution would be to keep it separate but 'bless' it with a reference in the docs. IMHO the same should be done with contrib.admin You could then have a django download with batteries and without.
- StavrosK 16y ago
  If I recall correctly, South is to be split into two parts (migrations and something else?) and half of it will be integrated into trunk.
mseebach 16y ago
Back when I first started looking at Django, the "apps" concept looked really promising. That you'd never need to worry about writing a comments-system again, because there would be a comments-app. That you don't need to integrate your main app with your blog and your CMS, because they'd just be separate apps that you'd drop in and forget about. But the mentioned apps .. aren't. They are tools, plug-ins and libraries. What a shame.
- stuartk 16y ago
  Some of the apps do just that, integrate nicely, don't get in the way of the rest of your project, and do their job. But many apps need all manner of templates, settings, url confs etc to use them. In those cases it's sometimes easier to write something simple yourself.
  - andybak 16y ago
    Apps could definitely be more modular and the recent addition of contrib.staticfiles to trunk will help greatly with, um, static files! Templates aren't really a problem, are they? Django will find the base ones and you can overload them if you want. settings should be handled elegantly with sensible defaults that you override if needed. And finally - the root url config is a bit of a bottleneck as every app that has URL's needs at least an include here. A registration system would be good but there are thorny issues to do with ordering of the URLs.
- po 16y ago
  Isn't that pretty much exactly what is delivered? Here's the comments app for example: http://docs.djangoproject.com/en/dev/ref/contrib/comments/ http://docs.djangoproject.com/en/dev/ref/contrib/comments/ For tagging you have a choice between django-tagit and django-tagging. Mingus for example took this to an extreme. Everything was a reusable app. Here's a good article from the developer about it: http://djangoadvent.com/1.2/everything-i-hate-about-mingus/ http://djangoadvent.com/1.2/everything-i-hate-about-mingus/ http://github.com/montylounge/django-mingus/ http://github.com/montylounge/django-mingus/ The one part of the reusable apps that tends not to get reused are the templates. I find the models, middleware, admin tools, etc… to be a pretty nice way to structure an app. Moreover, I think it's pretty easy to get caught in a very horizontally structured application because that's how they usually start. You put all of the models in one directory, all of the views in another, etc… I find Django urges you to think about how to slice your application into vertical chunks early on which benefits development.
levigross 16y ago
I hope django.contrib moves forward in the right direction and these makes these apps reusable
geoffbp 16y ago
my fav is probably sorl.thumbnail, followed by template_utils

42 points by niels 16y ago

marcc 16y ago

I don't know... Schema migration is rare and something I want complete control over while the debug toolbar is something I use constantly. I definitely would have submitted a vote for the toolbar.

StavrosK 16y ago
Schema migration is something I definitely want done right, otherwise production will break. If South didn't exist, I would think long and hard about adding a field, and I'd have to make changes manually in the database, in an error-prone and non-repeatable manner. In short, you use DjDT more often, but South is by far a much more important part. Which one could you live without, South or DjDT? I know which one I'd pick...

stuartk 16y ago

I still believe South should be included in Django itself, but the South devs wanted to keep it as a separate app. I remember when I first started learning Django. You follow the tutorial, write your models. Then you start playing about and want to add an extra field to a model and....oh wait, I need to either add it manually to the database or use a 3rd party app to do it. To my mind it's part of the workflow as you build an app.

endlessvoid94 16y ago
Agreed. This is one nice thing about rails, the migrations are part of the framework.
po 16y ago
It is definitely part of the workflow. I don't see how having it separate makes it any less of a part of your workflow. Git is also a part of my workflow. No harm in having it be separate. The advantage to keeping it separate is it allows South to release on it's own faster schedule. It gets features much quicker than the base framework. I imagine it will get rolled in some day, when the feature set stabilizes a bit.
- stuartk 16y ago
  Good point in regards to a faster release schedule for South. And yes, it is part of my workflow. But for a new Django developer, it's not obvious, as it's not part of the documentation.
  - po 16y ago
    The fact that it's not obvious is also a good point. I recently brought up the documentation issue on the mailing list and received a pretty encouraging response from Mr. Kaplan-Moss himself: http://groups.google.com/group/django-developers/browse_thread/thread/6e810d18249c2792 http://groups.google.com/group/django-developers/browse_thre... Django 1.3 is a tightening of the bolts release so I am going through and updating where improvements are needed and patching where I feel capable. Perhaps you or others would like to improve the documentation as well?
    - levigross 16y ago
      I hope they start to use a DVCS to kickstart the development.
  - andybak 16y ago
    The solution would be to keep it separate but 'bless' it with a reference in the docs. IMHO the same should be done with contrib.admin You could then have a django download with batteries and without.
StavrosK 16y ago
If I recall correctly, South is to be split into two parts (migrations and something else?) and half of it will be integrated into trunk.

mseebach 16y ago

Back when I first started looking at Django, the "apps" concept looked really promising. That you'd never need to worry about writing a comments-system again, because there would be a comments-app. That you don't need to integrate your main app with your blog and your CMS, because they'd just be separate apps that you'd drop in and forget about. But the mentioned apps .. aren't. They are tools, plug-ins and libraries. What a shame.

stuartk 16y ago
Some of the apps do just that, integrate nicely, don't get in the way of the rest of your project, and do their job. But many apps need all manner of templates, settings, url confs etc to use them. In those cases it's sometimes easier to write something simple yourself.
- andybak 16y ago
  Apps could definitely be more modular and the recent addition of contrib.staticfiles to trunk will help greatly with, um, static files! Templates aren't really a problem, are they? Django will find the base ones and you can overload them if you want. settings should be handled elegantly with sensible defaults that you override if needed. And finally - the root url config is a bit of a bottleneck as every app that has URL's needs at least an include here. A registration system would be good but there are thorny issues to do with ordering of the URLs.
po 16y ago
Isn't that pretty much exactly what is delivered? Here's the comments app for example: http://docs.djangoproject.com/en/dev/ref/contrib/comments/ http://docs.djangoproject.com/en/dev/ref/contrib/comments/ For tagging you have a choice between django-tagit and django-tagging. Mingus for example took this to an extreme. Everything was a reusable app. Here's a good article from the developer about it: http://djangoadvent.com/1.2/everything-i-hate-about-mingus/ http://djangoadvent.com/1.2/everything-i-hate-about-mingus/ http://github.com/montylounge/django-mingus/ http://github.com/montylounge/django-mingus/ The one part of the reusable apps that tends not to get reused are the templates. I find the models, middleware, admin tools, etc… to be a pretty nice way to structure an app. Moreover, I think it's pretty easy to get caught in a very horizontally structured application because that's how they usually start. You put all of the models in one directory, all of the views in another, etc… I find Django urges you to think about how to slice your application into vertical chunks early on which benefits development.

levigross 16y ago

I hope django.contrib moves forward in the right direction and these makes these apps reusable

geoffbp 16y ago

my fav is probably sorl.thumbnail, followed by template_utils