
My essential django package list - spapas82
https://spapas.github.io/2017/10/11/essential-django-packages/
======
ris
Django packages are often awwwwwfully tempting but the more of them you use
the more likely things are to start acting weird (they don't all play nicely
together) and the more pain you're going to have upgrading Django versions.
IRS really important to assess whether you _really need_ all the complexity
any add-on brings.

This also leafs me to favour more stay-out-of-my-way add one like django-silk
over django-debug-toolbar

~~~
spapas82
I have a different philosophy. If some functionality is offered by a good-
quality (supported, good docs etc) django package then go on and use it. If
you want to be DRY you shouldn't re-implement functionality that others have
already implemented. Also, after you use a package you more or less learn it
and it's easy to re-use it in your next project -- while if you implement your
own solution you'll most probably need to resort to horrendous copy and paste
from your old project to your new one to re-use it!

Also, as I already mention in my article, if you use a package and you use it
for its intented purpose you have a quick reference for some of your project's
functionality (f.e if you use django-waffle then you'll know that some parts
of the project can be enabled or disabled at will) - if instead you had
implemented everything yourself you (or the person that needs to understand
your project) would need to read everything to know what's happening. So, for
me, using a good django package does not add but actually _removes_ complexity
from your project!

I can't remember any package incompatibilities - instead as I already mention
in my article there are a lot of packages that work great together (django-
tables with django-filter, django-rest-framework with django-filter, django-
taggit with django-autocomplete-light etc).

Finally, I partially agree with your comment about more pain when upgrading
django versions however considering that

\- supported projects are usually upgraded a little after a new version of
django is out (most of them are already prepared before the new django version
is out since they can be tested using the beta version)

\- django keeps supporting (non LTS) old versions for 8 months (and 16 months
for securiy fixes) so in this time most probably all your dependecies will
have updated so as to support the new django version

\- all packages are open source so you can contribute to help move to the next
version

the upgrading pain should be very little... When I upgraded from django 1.10
to 1.11 I also upgraded all the packages I describe in the list and everything
worked without problems!

------
thraxil
Cool.

My "always on" Django apps:

    
    
      * django-compressor
      * django-debug-toolbar
      * django-waffle
      * django-jenkins
      * django-statsd-mozilla
      * django-markwhat
      * django-storages (to put static assets on S3/Cloudfront)
      * django-smoketest
    

Frequent additions as needed:

    
    
      * django-bootstrap3
      * django-rest-framework
      * django-filter
      * celery
      * wagtail
    

I used to use django-extensions everywhere, but it pulls in ipython and all of
ipython's dependencies, which gets pretty heavy.

~~~
nsomaru
Would love to know your thoughts on wagtail? I've been evaluating it (as
against django cms mostly), but resources seem generally scarce - there's no
big irc channel, the mailing list directs you to SO, and SO doesn't seem
particularly active on the wagtail front either. So where do you go for help
or if you need to bounce something off someone more experienced in Wagtail
than yourself?

Streamfield looks great! It seems a perfect replacement to my rigid model-per-
content-type approach.

Wagtail's deviation from standard Django patterns (no views!) are a little
concerning too.

~~~
tomd
I'm one of the Wagtail core developers. We made the mistake of spreading our
support across too many channels (Google Groups, Stack Overflow, IRC, semi-
private Slack) but we've made a clear decision to focus on Stack Overflow for
developer-related questions:

[https://stackoverflow.com/questions/tagged/wagtail](https://stackoverflow.com/questions/tagged/wagtail)

mainly as a result of this poll:

[https://twitter.com/WagtailCMS/status/801384753589080064](https://twitter.com/WagtailCMS/status/801384753589080064)

Please feel free to contact me directly (details in profile) if you're not
getting the support you need on SO.

------
orf
Great list! Thanks for sharing.

I'd like to recommend django-fsm[1], an essential package for anyone writing
workflow-driven applications (pretty common w/ Django).

1\. [https://github.com/kmmbvnr/django-fsm](https://github.com/kmmbvnr/django-
fsm)

~~~
spapas82
Hello thank you very much. I am aware of django-fsm (and it's sister project
django-viewflow) but I haven't used it in my projects that's why I didn't
include it in the list - all the other packages have been used and tested
extensively in various projects so I can vote for them.

Some projects that I had implemented and used workflows were implemented with
custom flows (by hand) using django-rules-light to keep a lid on who can do
what on each state.

django-fsm is definitely one of the packages I am going to use in future
projects that require extensive workflows.

------
chrxr
Great list, and thanks for giving Wagtail a shout-out! Your work on it back in
its early days is still very much appreciated.

~~~
spapas82
Thank you very much! Both contributing and working (using it as a CMS in
various projects) with Wagtail were an absolute joy!

------
legostormtroopr
Number one missing package so far is django-haystack. With how important
search is, having an easy django-like plugable search engine ready to go
quickly is a god send.

Add in the fact that it abstracts over different engines, means you can
develop locally with Whoosh (all pure python and virtualenv friendly) and
deploy to ElasticSearch without changing your code.

~~~
spapas82
Hello, I am aware of django-haystack but haven't used it in any of my projects
so I couldn't include it in my list.

Notice that the projects I worked on and needed full text searching were
implemented with Wagtail (CMS) which uses elasticsearch directly.

------
npolet
Great list. I use a few of these on all projects.

Interestingly, django-webpack-loader has completely replaced django-compressor
and all the other static bundlers. I like how configurable webpack is and how
much control it gives you.

Anyone else completely switched over? Every single static file runs through
webpack for me now, and I couldn't imagine ever going back.

~~~
spapas82
Hello, I am aware of webpack but I haven't jumped in the webpack wagon - the
tool I use from the node-js world for asset management is browserify which is
much simpler (I've written a couple of articles about it:
[https://spapas.github.io/2015/05/27/using-browserify-
watchif...](https://spapas.github.io/2015/05/27/using-browserify-watchify/)
and [https://spapas.github.io/2015/11/16/using-browserify-
es6/](https://spapas.github.io/2015/11/16/using-browserify-es6/)).

However, as I mention in the post, I don't using node-js tools if you don't
need em. If you have a couple of css / js files that don't do anything fancy
(i.e no es6, no require etc) then I don't thenk that there's any need to add a
huge dependency (node-js and friends) to your project. django-compressor (or
django-pipeline [https://github.com/jazzband/django-
pipeline](https://github.com/jazzband/django-pipeline) which is also good)
should be more than enough for your needs. Also, notice that webpack /
browserify don't understand javascript or css snipped that are inlined in your
django templates (django-compressor understands them all right).

------
Posibyte
I love this list, and I'm definitely tacking it on my hobby postboard at home.
(Especially for django-reversion which is something I've always wanted and
never knew existed!)

I would also like to thank OP for being really responsive to comments. I've
been feeling around your blog seeing all this other great content, and I
really appreciate the attention you give to people who comment and share :)

~~~
spapas82
Thank you very much for your kind words!

------
katelynsills
Great list! I noticed Tastypie wasn't included. I've really liked it, but are
there reasons I shouldn't be using it?

~~~
mycelium
In general Django REST Framework is a better package. Hooking in your own
customization is less ad-hoc with DRF than with Tastypie, I've found. The DRF
documentation is also absolutely stellar and the wider ecosystem around it is
really good.

edit: And to my sibling commenter's point, DRF has a funding model, so it's
being actively worked on full time.

~~~
collyw
Having used both, DRF is a lot more similar to standard Django. The views are
similar, and the serializers work very similarly to forms so it feels a lot
more consistent to use. I seem to remember a post a could of years back where
they said they weren't going to be doing more active development in Tastypie,
or something to that effect.

------
philipov
Could someone please concisely describe if there is a use-case where Django
offers utility above what Flask can provide?

~~~
speg
Built in everything. Users, auth, admin, ORM.

Flask is the opposite: Bring Your Own Everything. It's not hard to replicate
the functionality of Django but there is surely utility in having everything
boxed up and ready to go.

~~~
jon_richards
Never use the built in user. Always start a project with a custom user
extending abstract user.

At some point you'll want to customize the user in some way (like making the
username case insensitive), and you don't want to be dealing with migration
dependency conflicts when you do.

For some reason the Django team is really against any attempt to fix that.
They're almost hostile in their discussion of it.

~~~
thraxil
OK. Well, I've been building Django apps since around 2007/2008\. More than 50
deployed to production, many still running/maintained. Never once had a
problem using the built-in user model. Do you work in some vertical that makes
this a particularly common problem for you?

~~~
jastr
I don't think the parent comment is saying don't use the built-in user model.
The comment is suggesting to sub-class/extend the built-in user model. So you
can use much of the built-in functionality and add/change what you'd like, eg.
to add a birthday field

There are obviously other ways to do this, perhaps by creating a Profile model
that relates to a User.

~~~
jon_richards
Yes. Technically you should extend the abstract user model or things get real
broken real fast, but that still gives you all the functionality of the built-
in user model right out the gate.

The main reason is that if you ever want to change how the username works, it
will be a major pain to do if you've been using the built-in user model and
already run migrations.

------
polote
This list is impressive, but a lot of these packages are used to generate HTML
which is then not usable for SPA.

Do any of you have a similar list for SPA oriented projects ?

~~~
y4mi
honestly? use nodejs for that.

django can still give you the backend through DRF or django-graphene, but
frontend for SPA is (in my opinion as a dabbler that hates js) way better with
node.

take markojs as an example. creating an app with marko-cli gets you a simple
demo application with 3 webpages and you're ready to go. you can use concise
html syntax (way cleaner and i'm still astonished that there is no similie for
django). the stateful components syntax is _way_ cleaner. this is especially
true for for/if/whatever tags

like it or not js is the language of the web.

django is still wonderful if you're not focused on SPA applications though.
And this includes websites with contents which update through ajax calls.

~~~
drdaeman
I believe it works like this:

1\. Django for the backend. Nothing but an API (DRF, GraphQL, some custom
views or whatever one fancies) and - if server-side rendering is not necessary
- a catch-all view that spits out HTML file with the JS bundle. It either
doesn't know anything about the frontend, or, possibly, can read Webpack stats
file (using django-webpack-loader) to figure out correct bundle filename.

It may also run Django Admin Interface, independently from the SPA - as an
almost independent "back office" site.

2\. JS/TS/Elm/whatever and, probably, Webpack for the frontend/SPA itself. If
server-side rendering is desirable, a Node-based server. All it knows about
the backend is the API contract. Trying to somehow embed JS into Python/Django
is not easy, error-prone, and I just don't see any benefits of doing so.

3\. A router that sends requests to the correct piece. I've always used a
simplest-possible nginx setup with location /api/ { ... } and location / { ...
}.

------
collyw
It was a few years ago that I used it but I found django-autocomplete-light
pretty unfriendly and not very light. It was far easier to roll my own.

~~~
spapas82
Hello, I agree that previous versions of django-autocomplete-light were
cumbersome to use. However, since version 3 most of the magic has gone away:

1\. Add a class-based-view that returns the search data (inheriting from
autocomplete.Select2QuerySetView)

2\. Register that view with your urls.py as normally (but be sure to give it a
name)

3\. Add a form field by specifying its widget using the
autocomplete.ModelSelect2 widgt, passing it a url='view-name' parameter (which
is the view name you used in 2).

4\. Don't forget to include jquery and {{ form.media }} in the views that uses
your autocomplete.

5\. Done!

Seems pretty easy and friendly to me!

------
travelton
Very nice list. Bookmarking this!

One nitpick on your blog layout. I was clicking the h3 for each library, and
thought the links were broken. :)

~~~
spapas82
Hello, thank you very much!

Now that you mention it, I also find this behavior (clicking the header
returns you to the TOC) and since it can be easily fixed (change .. contents::
to .. contents:: :backlinks: none) it should have been fixed by now :)

------
disillusioned1
Great resource! Perhaps make it easier to find on your site by adding it to
your "Django" category?

~~~
spapas82
Thank you! Yes, I agree that the article fits better to the django category
than the python one so I moved it, thanks for the heads-up!

------
charred_toast
Great reference. Thank you, spapas82. Bookmarked!

------
eugeneionesco
Your site is full of juicy content, thanks!

