
Django plugins you shouldn't start without - hgezim
http://blog.hndigest.com/django-plugins-i-start-my-with/
======
aroman
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
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
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.

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

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

~~~
jdunck
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/#connec...](https://docs.djangoproject.com/en/dev/topics/signals/#connecting-
receiver-functions)

[2] [https://docs.djangoproject.com/en/dev/ref/request-
response/#...](https://docs.djangoproject.com/en/dev/ref/request-
response/#django.http.HttpRequest.is_ajax)

~~~
StavrosK
Thanks for your feedback, let me reply to it:

As JshWright said, the appeal of render_to is that it's a decorator, it does
clean up views by a lot.

The signals decorator is now obsolete, I also find ajax_response very handy
(when I'm not using CBVs), autostrip is a bit edge-casey, I agree.

get_object_or_None is pretty much 1.6's .first(), but there was no alternative
until 1.6. AutOneToOne/JSON fields are there because of convenience,
get_config I have no idea about (I didn't write these), StaticServer, also no
idea.

The thing is that this library has been out for years, and most of these
things didn't exist in core when it came out, so it was really handy in its
time. I've been using it for quite a few years, and that's also why I took up
maintenance of it.

In the long run, I'd like to see the things that make sense in it integrated
into core, especially the @render decorator.

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

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

~~~
ris
> 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
Ah, you're right there, if you're talking about a blog app, I agree with you.
I had much smaller pieces in mind, such as the packages I mentioned before.
Each one of those does one specific thing and does it well. Blogging is pretty
much the worst example here because it's highly, highly custom to each person
and easy enough to write that you wouldn't bother with a library, which would
end up not doing what you want in the long run anyway.

Something like shortuuid, on the other hand, is pretty much a slot-in.

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

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

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

------
robomartin
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?

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

~~~
jsmeaton
Not entirely true that the database is the main concern[0]. The overhead of
the framework/language has a massive impact.

That said, I'm not Google either, and I'm happily using django and love using
it.

[0] [http://www.techempower.com/blog/2013/03/28/frameworks-
round-...](http://www.techempower.com/blog/2013/03/28/frameworks-round-1/)

~~~
est
How about in Round 7 that Python surpasses Nodejs?

[http://www.techempower.com/benchmarks/#section=data-r7](http://www.techempower.com/benchmarks/#section=data-r7)

Python didn't beat NodeJS in Database queries though.

Yes Go is fast, but Go is also cluttered with its static type system.

Personally I feel pain to deal with flexible JSON marshal/unmarshal, in Python
dict() is nearly 100% identical with JS objects in value.

~~~
jsmeaton
> How about in Round 7 that Python surpasses Nodejs

I can't find what you're referring to. Node was still infront of Django in the
JSON benchmark.

Django (until 1.6) hasn't had connection pooling for the database either.
Updating those benchmarks with pooling should make significant differences.

But my point was that the framework itself can have a huge impact. Database
and other I/O does have overhead, and it may even be significant. But it's not
necessarily the biggest factor.

~~~
est
You are comparing a Web framework (Django) with a language+network runtime
(Nodejs).

The Nodejs web framework is Express, behind Bottle and Falcon.

~~~
jsmeaton
Oh, I see. But "python" wasn't represented, which confused me. There is still
a large discrepancy between the different frameworks in the javascript and
python set.

But the original point was that database and I/O make the largest difference.
After restricting the set of languages and frameworks to python and
javascript, I can only (now) agree.

109,000-5700 rps for JSON requests, and 4800-117 rps for multiple database
queries. Quite significant.

~~~
est
I agree with ya. There's big room for db connection improvement in Django.

------
goblin89
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/)

------
yeukhon
We are all eagerly waiting south to be merged into Django.
[https://github.com/django/django/commit/9aa358cedd1ad93c0f4c...](https://github.com/django/django/commit/9aa358cedd1ad93c0f4c20700db7016651dc0598)

Or have we?

~~~
jorde
We are but it will still need South or other app to actually command the
migrations if I have understood correctly.

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

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

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

------
monokrome
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
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/)

------
Spiritus
Yes `select email from auth_user;` is hard.

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

~~~
michaelmior
{{ block.super }} does the trick for me.

~~~
tcdent
That only works with templates that extend a base template, not ones included
inline.

~~~
michaelmior
This is true. But I've never felt that the need for something like sekizai in
practice based on how I structure templates.

------
skizm
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
Database migrations are being added to Django core, by the author of South.

------
gpsarakis
This app proves also very helpful if you use Nginx:
[https://github.com/andreiko/django_graceful](https://github.com/andreiko/django_graceful)

~~~
sheng
> 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/)

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

