8 ms·

Django plugins you shouldn't start without

170 points by hgezim 13y ago

Spiritus 13y ago
Yes `select email from auth_user;` is hard.
yeukhon 13y ago
We are all eagerly waiting south to be merged into Django. https://github.com/django/django/commit/9aa358cedd1ad93c0f4c20700db7016651dc0598 https://github.com/django/django/commit/9aa358cedd1ad93c0f4c... Or have we?
- jorde 13y ago
  We are but it will still need South or other app to actually command the migrations if I have understood correctly.
  - jsmeaton 13y ago
    Nope. Schema Migrations are built directly into django (scheduled for 1.7), and includes the runner. It's not just an API for other tools to use.
robomartin 13y ago
As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django for new projects rather than devoting that time to something like Go. Can't do both. Not enough time and we need to get things done. Now, I do appreciate that Python has a huge ecosystem and lots of very useful libraries out there. That alone might make the price of admission worth it. I also look at these benchmarks and it seems that PHP (something I am really trying to leave behind) frequently scored above the various Python ecosystems. Can someone put this into perspective for me? In the end performance can and is hugely important. What am I missing when looking at all of this?
- stiaje 13y ago
  Very often in web development, the kind of performance Go or Java delivers just isn't necessary. You'll often find that the time you spend on developing new features is much more important, and with python I think this can be significantly less.
- vdaniuk 13y ago
  I am also a novice and not an authority on Python, but can offer three reasons for using Python even if it is not fast as other languages. 1. Raw language speed is an important factor to consider but for some projects language syntax, community, ecosystem and libraries are much more significant. Those are python strong aspects. Due to its simple syntax, Python is very popular at mooc platforms, such as Coursera, edX and Udacity. Really lots of very good educational content and I mean MIT level good. 2. Usually web projects do not need to scale that much. Website traffic distribution follows power law so if you do not expect your project to be in top 1%, Django will usually handle all standard CRUD workloads. 3. There are Python bindings for many C libraries, for example image manipulation with C speeds is available using ImageMagick bindings.
- vikp 13y ago
  I think it really centers around ease of use, amount of libraries, and community support. Django is widely adopted, has a long history of use, and is relatively easy to get started with. Performance is obviously important, but there are plenty of major websites using Django, so it can scale. This is a decent thread on that: http://www.quora.com/Django-web-framework/What-is-the-highest-traffic-website-built-on-top-of-Django http://www.quora.com/Django-web-framework/What-is-the-highes... . Here is a great comparison of Go and Django: http://lincolnloop.com/blog/djangonaut-building-webapp-go-gorilla/ http://lincolnloop.com/blog/djangonaut-building-webapp-go-go... . I personally have used Django for quite a few projects, and haven't had any "I wish I used a different framework/language" moments.
- patio11 13y ago
  For many web programming tasks, your user-perceptible speed and/or maximum system loads will not be dominated by the performance of your web application but rather by database, I/O (including networking), and client performance (JS performance, aggressive asset caching, CDN usage, etc etc). Go or Java are wonderful languages if you have serious number-crunching needs or if cutting your server budget in half would save you a billion dollars. My server budget is $500 a month and if you doubled the performance of all of my servers it would be $500 a month. I'll elide the detailed explanation of the whole "User clicks a button" to "User sees something happen" HTTP request waterfall chart but my Rails app is generally less than 5% of it. YMMV if you're Google, but I'm not Google.
rMBP 13y ago
Wow, sekizai looks great. Removes many of my headaches with django's limited block system.
- michaelmior 13y ago
  {{ block.super }} does the trick for me.
  - tcdent 13y ago
    That only works with templates that extend a base template, not ones included inline.
    - michaelmior 13y ago
      This is true. But I've never felt that the need for something like sekizai in practice based on how I structure templates.
ris 13y ago
Excellent. Pile up your django with extensions, then look forward to the fun when you have to port your app from e.g. django 1.3 to 1.5 and find a new set of versions of all of your dependencies that work nicely together. And of course figure out a migration path for it all. That is, if extension xyz is still maintained at all. Lean is beautiful, people. Carefully assess every dependency you add, as each one has the potential to become a burden.
- dmishe 13y ago
  Yep
- StavrosK 13y ago
  Wait. If you need a piece of functionality, you either get something that works out of the box, or you spend X hours writing it. If the out-of-the-box thing breaks and you spend Y hours fixing it, then Y has to be much greater than X to not be worth it, which, in my experience, it never is. Not to mention that, if the library broke, then the thing you would have written would have probably broken as well, and you wouldn't have the benefit of a thousand other users who might have had (and fixed) the problem before you. This just smells of FUD to me, as it rarely is a problem to me in practice.
  - joshlegs 13y ago
    really have to agree with you. why would you ever spend time writing some functionality that someone else already has, unless what's out there is just total shite.
  - ris 13y ago
    > If you need a piece of functionality Depends what you mean by "need". Often when you need a piece of functionality, what you actually "need" is a small subset of what a third party app is wanting to provide, and I've often found simply using out-of-the-box apps for this adds a fairly huge amount of complexity that is just not needed. My favourite case in point would be adding very simple blog functionality to something - which is fairly quick & trivial in django, but out-of-the-box blog solutions promote themselves with tempting-features-that-you-dont-really-need that inadvertently add a lot of complexity and before you know it you're a few releases down the line and you realize that the author doesn't really know how to use South properly and your db ends up in a slight migration-state-limbo forevermore. Though note that I am _not_ saying don't use external dependencies - I use several of those listed in the article (I am a big fan of django-reversion) - but remember to look at everything with a critical eye before inclusion. > This just smells of FUD to me It's all very well and good saying that but a stack of previous bad experiences doesn't smell like FUD when you're on this end of them.
StavrosK 13y ago
What, no django-annoying? That's the first thing I ever use: https://github.com/skorokithakis/django-annoying https://github.com/skorokithakis/django-annoying That, and shortuuid: https://pypi.python.org/pypi/shortuuid/ https://pypi.python.org/pypi/shortuuid/ Disclosure: I maintain one and wrote the other, but they and South are the three things I use for every project.
- jorde 13y ago
  Django-annoying is freaking awesome, I have been using it for couple years now (get_object_or_None and render_to <3). Didn't know that you had taken it over from offline, great job.
- bigsassy 13y ago
  Love django-annoying too. It's always got a line in requirements.txt for my Django projects :)
- bmelton 13y ago
  ShortUUID looks like fun. I usually just get a UUID4 and grab the last section of the generated UID. Something like str(uuid.uuid4()).split("-")[4] I'd like to say that I then do a duplicate check, but I don't think I've ever had a collision, so I'm not actually 100% true that I do. Best case, you've saved me a database query, worst case, you've saved me a potentially painful Exception. Danke.
  - StavrosK 13y ago
    It's pretty unlikely that you'll get a collision if you grab enough digits, but hex is only 16 digits. One easily has 62ish characters available (ShortUUID removes lookalikes so people can still read and type the codes), so why not squeeze as much randomness in them as you can? That's pretty much why I wrote it.
- jdunck 13y ago
  django core here, some feedback on -annoying: It'd be nice if you were clear about what versions of django and python are supported. From django-annoying's feature list: * render_to - seems to be roughly equivalent to django.shortcuts.render * signals decorator - now in core[1] (since 1.3) * ajax_response - seems useful, though might make sense to check request.is_ajax[2] * autostrip - hmm, seems oddly edge case-y, I definitely wouldn't apply it to all my forms * get_object_or_None - nifty * AutoOneToOneField - assumes the related model is valid with only the FK filled in, which seems fairly unlikely in many OneToOne cases. I'm not sure if this was proposed to core, but I'd think it would need some sort of default= fillin feature to be more generally useful. * JSONField - soo many competing and variously featureful implementations. This has been discussed a few times; it seems fairly easy to implement and hard to gain consensus. I wish we could get it in core, but the juice doesn't seem worth the squeeze. * get_config - I don't think I understand the purpose of this, unless you're just trying to be more intention-revealing than getattr(settings, ...) * HttpResponseReload - nifty * StaticServer - I don't think I understand why you wouldn't want to config urls.py instead. [1] https://docs.djangoproject.com/en/dev/topics/signals/#connecting-receiver-functions https://docs.djangoproject.com/en/dev/topics/signals/#connec... [2] https://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpRequest.is_ajax https://docs.djangoproject.com/en/dev/ref/request-response/#...
jorde 13y ago
This seems pretty excessive and I'm not even a purist (does one really need to graph models?). Only Django specific plugins that I rely on are South, django-annoying [1] and djorm-ext-expressions [2] but I couldn't see myself building anything larger without Celery anymore. [1]: https://bitbucket.org/offline/django-annoying https://bitbucket.org/offline/django-annoying [2]: https://github.com/niwibe/djorm-ext-expressions https://github.com/niwibe/djorm-ext-expressions
spmurrayzzz 13y ago
I don't think I'd ever feel comfortable starting a Django project of any size without using South. Wish I had known about it since the beginning of my time with Django. Migration implementations for any platform have always been somewhat vexing for me, but South has been all but automatic for me. I've never had to deviate from `schemamigration app --auto && migrate app`.
- jsmeaton 13y ago
  I'm in the unfortunate situation where we use Oracle as the backend database on our projects, which South has never really properly supported. I've done without it, and it isn't very nice. On the other hand, I ensure that every change that needs to be made to the schema can happen at any time, and both new and old versions of the code will happily work. I believe this helps with upgrading in that there is no delay during deployment and migration. Having not used south on a real project though, I'm unsure if this is a false benefit.
aroman 13y ago
Maybe I'm delusional, but even as someone who has worked pretty extensively (4 months of full stack Django development) with Django, posts like these things make me want to stay away from Django. I read this post, and I see bandaids. I see bloat, and I see warts. I don't want to build on a codebase that needs 5 extensions out of the box to be sane. Granted, I know this is not the real story with Django. It is a rather lovely, if rather rigid and stubborn framework (at least it was when I was writing with in circa 1.3). And it is powerful. But, and this is my point, it seems to me that there is almost no reason I would use Django over something like flask for anything but the most basic of apps. Any time you need to do "serious" work — beyond cookie-cutter stuff — you're going to need to seriously extend Django (or any other web framework for that matter, in my experience/humble opinion). And then it gets ugly, and you're better off building from the ground up on a minimal codebase than trying to contort an existing one to do what you need it to. Actually, most of my thoughts have been summed up 5 years ago by one of Flikr's lead architects (iirc) at DjangoCon '08 in a brilliant (and hilarious) talk: http://www.youtube.com/watch?v=i6Fr65PFqfk http://www.youtube.com/watch?v=i6Fr65PFqfk
- bmelton 13y ago
  If it helps any, as someone who's been building Django sites for years, I will say that while all of those are at least handy, absolutely none of them is needed. On the list, the only one I use with any regularity is South, which I do consider must-have. That said, it seems that the Django core team agrees, as it's being (or maybe is even finished) pulled into Django core.
  - thatthatis 13y ago
    Agreed. The only must have on this list is south. After that, I personally add allauth, storages, and s3-folder-storages as well, but that's a personal preference thing and there are very good reasons to use alternatives to each of those components.
  - rmc 13y ago
    Totally agree. The title of the submitted most is a bit extreme, these aren't "Django plugins you shouldn't start without" these are "Django plugins that are nice to have". It's false, as the grand parent comment thinks, to presume that django "needs 5 extensions out of the box to be sane". I've been working with django full time for 3 years and the only one I use is South.
monokrome 13y ago
In context of this article (at least), Sekizai is useless. You've been able to do this out-of-the-box with Django for a very long time. You can always reference inherited content in a Django block with {{ block.super }}. This feature has been around since AT LEAST v1.1. That's when I found the feature.
- ojii 13y ago
  author of sekizai here. you seem to misunderstand what sekizai does. it's not a replacement for block.super. it's main points are support for included templates, for loops and being able to put content anywhere in the template from anywhere. It is however entirely possible that you have no use case for it, but dismissing it as useless is a bit harsh in my opinion. Further reading on why sekizai and what it does in this blog post: http://ojii.ch/post/why-sekizai/ http://ojii.ch/post/why-sekizai/
- ojii 13y ago
  author of sekizai here. you seem to misunderstand what sekizai does. it's not a replacement for block.super. it's main points are support for included templates, for loops and being able to put content anywhere in the template from anywhere. It is however entirely possible that you have no use case for it, but dismissing it as useless is a bit harsh in my opinion. Further reading on why sekizai and what it does in this blog post: http://ojii.ch/post/why-sekizai/ http://ojii.ch/post/why-sekizai/
- ojii 13y ago
  author of sekizai here. you seem to misunderstand what sekizai does. it's not a replacement for block.super. it's main points are support for included templates, for loops and being able to put content anywhere in the template from anywhere. It is however entirely possible that you have no use case for it, but dismissing it as useless is a bit harsh in my opinion. Further reading on why sekizai and what it does in this blog post: http://ojii.ch/post/why-sekizai/ http://ojii.ch/post/why-sekizai/
leetrout 13y ago
How is Django Debug Toolbar not on that list? If you are doing anything more than a simple CRUD, and heck, even if that's all, you should at least peek at how many queries are happening in views and how page render timing is broken down. https://github.com/django-debug-toolbar/django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar
streeter 13y ago
FWIW, South won't totally be necessary after Django 1.7. Django 1.7 is getting support for migrations built-in.
damon_c 13y ago
If you're using or considering using class based views, I have found Django Vanilla Views to be pretty much a pure win. They really make class based views feel so much more natural. I'm not going back. http://django-vanilla-views.org http://django-vanilla-views.org
jdunck 13y ago
If we're just plugging useful packages, I'd suggest these as useful and broadly applicable: * django-debug-toolbar * django-secure * django-celery * django_compressor
gpsarakis 13y ago
This app proves also very helpful if you use Nginx: https://github.com/andreiko/django_graceful https://github.com/andreiko/django_graceful
- sheng 13y ago
  > Django Graceful is a set of commands for deployment > of django projects as fastcgi backends. Or just use uwsgi[1] and supervisord[2] if possible. [1] http://uwsgi-docs.readthedocs.org/en/latest/ http://uwsgi-docs.readthedocs.org/en/latest/ [2] http://supervisord.org/ http://supervisord.org/
skizm 13y ago
Why is south not number one in flaming gold letters? Seriously, south should just be part of django at this point and it is insane that there isn't this functionality built in. Is changing your data models after you started development so crazy?
- rmc 13y ago
  Database migrations are being added to Django core, by the author of South.
goblin89 13y ago
I respectfully disagree with OP. I would say that django_extensions is handy enough to have it included (mainly for the sake of shell_plus and runserver_plus), South is invaluable (although migrations are going into the core in near future[0]), but others—it very much depends on the project. sekizai is one I've never heard about before. Judging from the first sight, I think it can make templating more flexible, but at the cost of increased complexity. Earlier I thought that reversion is great to have by default, and I was adding it to every project. Then, as I recall, mysterious errors started popping up one day in one project after Django update. They turned out to have something to do with reversion compatibility. I looked into it and found that we had no use cases for reversion—I could simply throw it away without any consequences, which I promptly did. I've used grappelli for a while, but in the end I found its UI less usable than native Django admin UI. (Recently I stumbled across http://djangosuit.com/ http://djangosuit.com/ — this one does seem more functional, although I've never used it in my projects yet.) [0] https://docs.djangoproject.com/en/dev/topics/migrations/ https://docs.djangoproject.com/en/dev/topics/migrations/
tehwalrus 13y ago
isn't the South functionality there out of the box in rails? I've only ever written one rails app in my life, and I now use (non-Django) python all the time, but needing a 3rd party library to handle db migrations sounds like madness, and makes me want to re-learn ruby rather than use Django.

170 points by hgezim 13y ago

Yes `select email from auth_user;` is hard.

We are all eagerly waiting south to be merged into Django. https://github.com/django/django/commit/9aa358cedd1ad93c0f4c20700db7016651dc0598 https://github.com/django/django/commit/9aa358cedd1ad93c0f4c... Or have we?

jorde 13y ago
We are but it will still need South or other app to actually command the migrations if I have understood correctly.
- jsmeaton 13y ago
  Nope. Schema Migrations are built directly into django (scheduled for 1.7), and includes the runner. It's not just an API for other tools to use.

robomartin 13y ago

As someone who is just starting to dive into Django and Python in general I have to admit being confused by benchmark after benchmark that puts Python near to the bottom of the performance curve when compared to other technologies (Go being one that jumps out at me). I have to admit that part of me is wondering if I am making the right decision in investing time, effort and money getting up to speed on Python/Django for new projects rather than devoting that time to something like Go. Can't do both. Not enough time and we need to get things done. Now, I do appreciate that Python has a huge ecosystem and lots of very useful libraries out there. That alone might make the price of admission worth it. I also look at these benchmarks and it seems that PHP (something I am really trying to leave behind) frequently scored above the various Python ecosystems. Can someone put this into perspective for me? In the end performance can and is hugely important. What am I missing when looking at all of this?

stiaje 13y ago
Very often in web development, the kind of performance Go or Java delivers just isn't necessary. You'll often find that the time you spend on developing new features is much more important, and with python I think this can be significantly less.
vdaniuk 13y ago
I am also a novice and not an authority on Python, but can offer three reasons for using Python even if it is not fast as other languages. 1. Raw language speed is an important factor to consider but for some projects language syntax, community, ecosystem and libraries are much more significant. Those are python strong aspects. Due to its simple syntax, Python is very popular at mooc platforms, such as Coursera, edX and Udacity. Really lots of very good educational content and I mean MIT level good. 2. Usually web projects do not need to scale that much. Website traffic distribution follows power law so if you do not expect your project to be in top 1%, Django will usually handle all standard CRUD workloads. 3. There are Python bindings for many C libraries, for example image manipulation with C speeds is available using ImageMagick bindings.
vikp 13y ago
I think it really centers around ease of use, amount of libraries, and community support. Django is widely adopted, has a long history of use, and is relatively easy to get started with. Performance is obviously important, but there are plenty of major websites using Django, so it can scale. This is a decent thread on that: http://www.quora.com/Django-web-framework/What-is-the-highest-traffic-website-built-on-top-of-Django http://www.quora.com/Django-web-framework/What-is-the-highes... . Here is a great comparison of Go and Django: http://lincolnloop.com/blog/djangonaut-building-webapp-go-gorilla/ http://lincolnloop.com/blog/djangonaut-building-webapp-go-go... . I personally have used Django for quite a few projects, and haven't had any "I wish I used a different framework/language" moments.
patio11 13y ago
For many web programming tasks, your user-perceptible speed and/or maximum system loads will not be dominated by the performance of your web application but rather by database, I/O (including networking), and client performance (JS performance, aggressive asset caching, CDN usage, etc etc). Go or Java are wonderful languages if you have serious number-crunching needs or if cutting your server budget in half would save you a billion dollars. My server budget is $500 a month and if you doubled the performance of all of my servers it would be $500 a month. I'll elide the detailed explanation of the whole "User clicks a button" to "User sees something happen" HTTP request waterfall chart but my Rails app is generally less than 5% of it. YMMV if you're Google, but I'm not Google.

rMBP 13y ago

Wow, sekizai looks great. Removes many of my headaches with django's limited block system.

michaelmior 13y ago
{{ block.super }} does the trick for me.
- tcdent 13y ago
  That only works with templates that extend a base template, not ones included inline.
  - michaelmior 13y ago
    This is true. But I've never felt that the need for something like sekizai in practice based on how I structure templates.

ris 13y ago

Excellent. Pile up your django with extensions, then look forward to the fun when you have to port your app from e.g. django 1.3 to 1.5 and find a new set of versions of all of your dependencies that work nicely together. And of course figure out a migration path for it all. That is, if extension xyz is still maintained at all. Lean is beautiful, people. Carefully assess every dependency you add, as each one has the potential to become a burden.

dmishe 13y ago
Yep
StavrosK 13y ago
Wait. If you need a piece of functionality, you either get something that works out of the box, or you spend X hours writing it. If the out-of-the-box thing breaks and you spend Y hours fixing it, then Y has to be much greater than X to not be worth it, which, in my experience, it never is. Not to mention that, if the library broke, then the thing you would have written would have probably broken as well, and you wouldn't have the benefit of a thousand other users who might have had (and fixed) the problem before you. This just smells of FUD to me, as it rarely is a problem to me in practice.
- joshlegs 13y ago
  really have to agree with you. why would you ever spend time writing some functionality that someone else already has, unless what's out there is just total shite.
- ris 13y ago
  > If you need a piece of functionality Depends what you mean by "need". Often when you need a piece of functionality, what you actually "need" is a small subset of what a third party app is wanting to provide, and I've often found simply using out-of-the-box apps for this adds a fairly huge amount of complexity that is just not needed. My favourite case in point would be adding very simple blog functionality to something - which is fairly quick & trivial in django, but out-of-the-box blog solutions promote themselves with tempting-features-that-you-dont-really-need that inadvertently add a lot of complexity and before you know it you're a few releases down the line and you realize that the author doesn't really know how to use South properly and your db ends up in a slight migration-state-limbo forevermore. Though note that I am _not_ saying don't use external dependencies - I use several of those listed in the article (I am a big fan of django-reversion) - but remember to look at everything with a critical eye before inclusion. > This just smells of FUD to me It's all very well and good saying that but a stack of previous bad experiences doesn't smell like FUD when you're on this end of them.

StavrosK 13y ago

What, no django-annoying? That's the first thing I ever use: https://github.com/skorokithakis/django-annoying https://github.com/skorokithakis/django-annoying That, and shortuuid: https://pypi.python.org/pypi/shortuuid/ https://pypi.python.org/pypi/shortuuid/ Disclosure: I maintain one and wrote the other, but they and South are the three things I use for every project.

jorde 13y ago
Django-annoying is freaking awesome, I have been using it for couple years now (get_object_or_None and render_to <3). Didn't know that you had taken it over from offline, great job.
bigsassy 13y ago
Love django-annoying too. It's always got a line in requirements.txt for my Django projects :)
bmelton 13y ago
ShortUUID looks like fun. I usually just get a UUID4 and grab the last section of the generated UID. Something like str(uuid.uuid4()).split("-")[4] I'd like to say that I then do a duplicate check, but I don't think I've ever had a collision, so I'm not actually 100% true that I do. Best case, you've saved me a database query, worst case, you've saved me a potentially painful Exception. Danke.
- StavrosK 13y ago
  It's pretty unlikely that you'll get a collision if you grab enough digits, but hex is only 16 digits. One easily has 62ish characters available (ShortUUID removes lookalikes so people can still read and type the codes), so why not squeeze as much randomness in them as you can? That's pretty much why I wrote it.
jdunck 13y ago
django core here, some feedback on -annoying: It'd be nice if you were clear about what versions of django and python are supported. From django-annoying's feature list: * render_to - seems to be roughly equivalent to django.shortcuts.render * signals decorator - now in core[1] (since 1.3) * ajax_response - seems useful, though might make sense to check request.is_ajax[2] * autostrip - hmm, seems oddly edge case-y, I definitely wouldn't apply it to all my forms * get_object_or_None - nifty * AutoOneToOneField - assumes the related model is valid with only the FK filled in, which seems fairly unlikely in many OneToOne cases. I'm not sure if this was proposed to core, but I'd think it would need some sort of default= fillin feature to be more generally useful. * JSONField - soo many competing and variously featureful implementations. This has been discussed a few times; it seems fairly easy to implement and hard to gain consensus. I wish we could get it in core, but the juice doesn't seem worth the squeeze. * get_config - I don't think I understand the purpose of this, unless you're just trying to be more intention-revealing than getattr(settings, ...) * HttpResponseReload - nifty * StaticServer - I don't think I understand why you wouldn't want to config urls.py instead. [1] https://docs.djangoproject.com/en/dev/topics/signals/#connecting-receiver-functions https://docs.djangoproject.com/en/dev/topics/signals/#connec... [2] https://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpRequest.is_ajax https://docs.djangoproject.com/en/dev/ref/request-response/#...

jorde 13y ago

This seems pretty excessive and I'm not even a purist (does one really need to graph models?). Only Django specific plugins that I rely on are South, django-annoying [1] and djorm-ext-expressions [2] but I couldn't see myself building anything larger without Celery anymore. [1]: https://bitbucket.org/offline/django-annoying https://bitbucket.org/offline/django-annoying [2]: https://github.com/niwibe/djorm-ext-expressions https://github.com/niwibe/djorm-ext-expressions

spmurrayzzz 13y ago

I don't think I'd ever feel comfortable starting a Django project of any size without using South. Wish I had known about it since the beginning of my time with Django. Migration implementations for any platform have always been somewhat vexing for me, but South has been all but automatic for me. I've never had to deviate from `schemamigration app --auto && migrate app`.

jsmeaton 13y ago
I'm in the unfortunate situation where we use Oracle as the backend database on our projects, which South has never really properly supported. I've done without it, and it isn't very nice. On the other hand, I ensure that every change that needs to be made to the schema can happen at any time, and both new and old versions of the code will happily work. I believe this helps with upgrading in that there is no delay during deployment and migration. Having not used south on a real project though, I'm unsure if this is a false benefit.

aroman 13y ago

Maybe I'm delusional, but even as someone who has worked pretty extensively (4 months of full stack Django development) with Django, posts like these things make me want to stay away from Django. I read this post, and I see bandaids. I see bloat, and I see warts. I don't want to build on a codebase that needs 5 extensions out of the box to be sane. Granted, I know this is not the real story with Django. It is a rather lovely, if rather rigid and stubborn framework (at least it was when I was writing with in circa 1.3). And it is powerful. But, and this is my point, it seems to me that there is almost no reason I would use Django over something like flask for anything but the most basic of apps. Any time you need to do "serious" work — beyond cookie-cutter stuff — you're going to need to seriously extend Django (or any other web framework for that matter, in my experience/humble opinion). And then it gets ugly, and you're better off building from the ground up on a minimal codebase than trying to contort an existing one to do what you need it to. Actually, most of my thoughts have been summed up 5 years ago by one of Flikr's lead architects (iirc) at DjangoCon '08 in a brilliant (and hilarious) talk: http://www.youtube.com/watch?v=i6Fr65PFqfk http://www.youtube.com/watch?v=i6Fr65PFqfk

bmelton 13y ago
If it helps any, as someone who's been building Django sites for years, I will say that while all of those are at least handy, absolutely none of them is needed. On the list, the only one I use with any regularity is South, which I do consider must-have. That said, it seems that the Django core team agrees, as it's being (or maybe is even finished) pulled into Django core.
- thatthatis 13y ago
  Agreed. The only must have on this list is south. After that, I personally add allauth, storages, and s3-folder-storages as well, but that's a personal preference thing and there are very good reasons to use alternatives to each of those components.
- rmc 13y ago
  Totally agree. The title of the submitted most is a bit extreme, these aren't "Django plugins you shouldn't start without" these are "Django plugins that are nice to have". It's false, as the grand parent comment thinks, to presume that django "needs 5 extensions out of the box to be sane". I've been working with django full time for 3 years and the only one I use is South.

monokrome 13y ago

In context of this article (at least), Sekizai is useless. You've been able to do this out-of-the-box with Django for a very long time. You can always reference inherited content in a Django block with {{ block.super }}. This feature has been around since AT LEAST v1.1. That's when I found the feature.

ojii 13y ago
author of sekizai here. you seem to misunderstand what sekizai does. it's not a replacement for block.super. it's main points are support for included templates, for loops and being able to put content anywhere in the template from anywhere. It is however entirely possible that you have no use case for it, but dismissing it as useless is a bit harsh in my opinion. Further reading on why sekizai and what it does in this blog post: http://ojii.ch/post/why-sekizai/ http://ojii.ch/post/why-sekizai/
ojii 13y ago
author of sekizai here. you seem to misunderstand what sekizai does. it's not a replacement for block.super. it's main points are support for included templates, for loops and being able to put content anywhere in the template from anywhere. It is however entirely possible that you have no use case for it, but dismissing it as useless is a bit harsh in my opinion. Further reading on why sekizai and what it does in this blog post: http://ojii.ch/post/why-sekizai/ http://ojii.ch/post/why-sekizai/
ojii 13y ago
author of sekizai here. you seem to misunderstand what sekizai does. it's not a replacement for block.super. it's main points are support for included templates, for loops and being able to put content anywhere in the template from anywhere. It is however entirely possible that you have no use case for it, but dismissing it as useless is a bit harsh in my opinion. Further reading on why sekizai and what it does in this blog post: http://ojii.ch/post/why-sekizai/ http://ojii.ch/post/why-sekizai/

leetrout 13y ago

How is Django Debug Toolbar not on that list? If you are doing anything more than a simple CRUD, and heck, even if that's all, you should at least peek at how many queries are happening in views and how page render timing is broken down. https://github.com/django-debug-toolbar/django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar

streeter 13y ago

FWIW, South won't totally be necessary after Django 1.7. Django 1.7 is getting support for migrations built-in.

damon_c 13y ago

If you're using or considering using class based views, I have found Django Vanilla Views to be pretty much a pure win. They really make class based views feel so much more natural. I'm not going back. http://django-vanilla-views.org http://django-vanilla-views.org

jdunck 13y ago

If we're just plugging useful packages, I'd suggest these as useful and broadly applicable: * django-debug-toolbar * django-secure * django-celery * django_compressor

gpsarakis 13y ago

This app proves also very helpful if you use Nginx: https://github.com/andreiko/django_graceful https://github.com/andreiko/django_graceful

sheng 13y ago
> Django Graceful is a set of commands for deployment > of django projects as fastcgi backends. Or just use uwsgi[1] and supervisord[2] if possible. [1] http://uwsgi-docs.readthedocs.org/en/latest/ http://uwsgi-docs.readthedocs.org/en/latest/ [2] http://supervisord.org/ http://supervisord.org/

skizm 13y ago

Why is south not number one in flaming gold letters? Seriously, south should just be part of django at this point and it is insane that there isn't this functionality built in. Is changing your data models after you started development so crazy?

rmc 13y ago
Database migrations are being added to Django core, by the author of South.

goblin89 13y ago

I respectfully disagree with OP. I would say that django_extensions is handy enough to have it included (mainly for the sake of shell_plus and runserver_plus), South is invaluable (although migrations are going into the core in near future[0]), but others—it very much depends on the project. sekizai is one I've never heard about before. Judging from the first sight, I think it can make templating more flexible, but at the cost of increased complexity. Earlier I thought that reversion is great to have by default, and I was adding it to every project. Then, as I recall, mysterious errors started popping up one day in one project after Django update. They turned out to have something to do with reversion compatibility. I looked into it and found that we had no use cases for reversion—I could simply throw it away without any consequences, which I promptly did. I've used grappelli for a while, but in the end I found its UI less usable than native Django admin UI. (Recently I stumbled across http://djangosuit.com/ http://djangosuit.com/ — this one does seem more functional, although I've never used it in my projects yet.) [0] https://docs.djangoproject.com/en/dev/topics/migrations/ https://docs.djangoproject.com/en/dev/topics/migrations/

tehwalrus 13y ago

isn't the South functionality there out of the box in rails? I've only ever written one rails app in my life, and I now use (non-Django) python all the time, but needing a 3rd party library to handle db migrations sounds like madness, and makes me want to re-learn ruby rather than use Django.