Django plugins you shouldn't start without

Maybe I&#x27;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.<p>I read this post, and I see bandaids. I see bloat, and I see warts. I don&#x27;t want to build on a codebase that needs 5 extensions out of the box to be sane.<p>Granted, I know this is <i>not</i> 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.<p>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 &quot;serious&quot; work — beyond cookie-cutter stuff — you&#x27;re going to need to seriously extend Django (or any other web framework for that matter, in my experience&#x2F;humble opinion). And then it gets ugly, and you&#x27;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.<p>Actually, most of my thoughts have been summed up 5 years ago by one of Flikr&#x27;s lead architects (iirc) at DjangoCon &#x27;08 in a brilliant (and hilarious) talk: <a href="http://www.youtube.com/watch?v=i6Fr65PFqfk" rel="nofollow">http:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=i6Fr65PFqfk</a>

How is Django Debug Toolbar not on that list?<p>If you are doing anything more than a simple CRUD, and heck, even if that&#x27;s all, you should at least peek at how many queries are happening in views and how page render timing is broken down.<p><a href="https://github.com/django-debug-toolbar/django-debug-toolbar" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;django-debug-toolbar&#x2F;django-debug-toolbar</a>

What, no django-annoying? That&#x27;s the first thing I ever use:<p><a href="https://github.com/skorokithakis/django-annoying" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;skorokithakis&#x2F;django-annoying</a><p>That, and shortuuid:<p><a href="https://pypi.python.org/pypi/shortuuid/" rel="nofollow">https:&#x2F;&#x2F;pypi.python.org&#x2F;pypi&#x2F;shortuuid&#x2F;</a><p>Disclosure: I maintain one and wrote the other, but they and South are the three things I use for every project.

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.<p>Lean is beautiful, people. Carefully assess every dependency you add, as each one has the potential to become a burden.

I don&#x27;t think I&#x27;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.<p>Migration implementations for any platform have always been somewhat vexing for me, but South has been all but automatic for me. I&#x27;ve never had to deviate from `schemamigration app --auto &amp;&amp; migrate app`.

If you&#x27;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&#x27;m not going back.<p><a href="http://django-vanilla-views.org" rel="nofollow">http:&#x2F;&#x2F;django-vanilla-views.org</a>

This seems pretty excessive and I&#x27;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&#x27;t see myself building anything larger without Celery anymore.<p>[1]: <a href="https://bitbucket.org/offline/django-annoying" rel="nofollow">https:&#x2F;&#x2F;bitbucket.org&#x2F;offline&#x2F;django-annoying</a> [2]: <a href="https://github.com/niwibe/djorm-ext-expressions" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;niwibe&#x2F;djorm-ext-expressions</a>

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).<p>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&#x2F;Django for new projects rather than devoting that time to something like Go. Can&#x27;t do both. Not enough time and we need to get things done.<p>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.<p>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?

I respectfully disagree with OP.<p>I would say that <i>django_extensions</i> is handy enough to have it included (mainly for the sake of shell_plus and runserver_plus), <i>South</i> is invaluable (although migrations are going into the core in near future[0]), but others—it very much depends on the project.<p><i>sekizai</i> is one I&#x27;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.<p>Earlier I thought that <i>reversion</i> 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 <i>no</i> use cases for reversion—I could simply throw it away without any consequences, which I promptly did.<p>I&#x27;ve used <i>grappelli</i> for a while, but in the end I found its UI less usable than native Django admin UI. (Recently I stumbled across <a href="http://djangosuit.com/" rel="nofollow">http:&#x2F;&#x2F;djangosuit.com&#x2F;</a> — this one does seem more functional, although I&#x27;ve never used it in my projects yet.)<p>[0] <a href="https://docs.djangoproject.com/en/dev/topics/migrations/" rel="nofollow">https:&#x2F;&#x2F;docs.djangoproject.com&#x2F;en&#x2F;dev&#x2F;topics&#x2F;migrations&#x2F;</a>

We are all eagerly waiting south to be merged into Django. <a href="https://github.com/django/django/commit/9aa358cedd1ad93c0f4c20700db7016651dc0598" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;django&#x2F;django&#x2F;commit&#x2F;9aa358cedd1ad93c0f4c...</a><p>Or have we?

If we&#x27;re just plugging useful packages, I&#x27;d suggest these as useful and broadly applicable:<p><pre><code> * django-debug-toolbar * django-secure * django-celery * django_compressor</code></pre>

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

In context of this article (at least), Sekizai is useless. You&#x27;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&#x27;s when I found the feature.

Yes `select email from auth_user;` is hard.

Wow, sekizai looks great. Removes many of my headaches with django&#x27;s limited block system.

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&#x27;t this functionality built in. Is changing your data models after you started development so crazy?

This app proves also very helpful if you use Nginx: <a href="https://github.com/andreiko/django_graceful" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;andreiko&#x2F;django_graceful</a>

isn&#x27;t the South functionality there out of the box in rails? I&#x27;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.