Earlier this year, I wrote an article that was sort of a mid-year review of popular Django projects from Github. This article follows up on that one. My criteria is slightly different, so skip to the end of the article if you want to know how I selected these projects
The Top 10
Easily add a dashboard with widgets to django-admin. Basically, use this thing for adding simple reporting needs where you want some visualizations added easily, but don’t want to spend a lot of time designing a custom display.
An extensible, full-featured, moderately-opinionated workflow engine. Could be useful for rolling your own ERP. Also, features a pretty nice looking GUI.
Compatible with Python 2 and 3; Django 1.9. Important note: code base hasn’t had any commits since Aug 4th, 2016, nor have there been any issues closed or PRs made since April 2016, so I hope this project is still being maintained.
Lets you keep a history of all changes to a particular model’s field. Store the field’s name, value, date and time of change, and the user that changed it.
While all this sounds close to django-reversion, please note that it isn’t a competing solution. Reversion is about tracking all the fields on a model.
Field-history lets you track specific field or set of fields instead, and it’s interested in solving only that problem. In fact, the maintainers closed an issue that would make this package compete with reversion.
Compatible with Python 2.7/3.2+; Django 1.7+.
I was on the line about including this project since its use-case seems so narrow at this point. But here it is.
graphene-django lets you implement a GraphQL API. What is GraphQL? To be overly simplistic, it’s a declarative JSON syntax that’s meant to feel like SQL: ask for data, not how to get the data, and get results back. Effectively, it’s an alternative to REST APIs that’s being pushed by Facebook.
So why is this project called graphene-django? Graphene is the python reference implementation of GraphQL.
I think this library is seeing some inflated support from people wanting to push React in the Django community, because Facebook also released relay, which is the React package to support requesting data from GraphQL endpoints.
So if your stack includes React, and you’re getting some strain from using a REST API, this project might be useful for you.
Appears to be compatible with Python 2.7/3.4–3.5; Django 1.6–1.10. (They don’t actually state that, but that’s what is passing on their builds.)
This package is a backend for caching that uses disk. Pretty obvious. But it argues that it can be as performant as in-memory caching for the fetching operation (not setting or deleting, though.) Quite the claim, but here’s the benchmark below.
Compatible with Python 2.7/3.4–3.5. Only tested on Django 1.9 currently.
If you want a REST API, but think that DRF has too much configuration, then this project was made for you. It literally adds a REST API onto django-admin endpoints with maybe 3 lines of code. So it’s extremely light.
That said, the project has no setup.py file, so you’ll literally have to clone the repo and copy the files into you project.
Additionally, there are no tests on this project yet, so compatibility is unknown. I’d expect probably Django 1.9 compatibility, but that’s a guess.
This project provides two very simple features: (1) allow a user to purge sessions from other devices, and(2) allow an admin to force a password reset on a specific user.
That’s all. Not very fancy, but extremely useful if you’re working on a project where the built-in auth features for Django are not sufficient for you.
Compatible with Python 2.7/3.4–3.5 and Django 1.8-1.9.
Another narrow feature set here: effectively, this package provides protection against accidentally making materially changes in your SQL queries.
You accomplish this by (1) writing a test using the provided context manager and (2) running that test locally, and(3) committing the resulting file to source control. Any subsequent running of that original test will compare the previously outputted file.
For example, using this project would prevent you from accidentally adding a where clause or changing a sort or adding an entirely new query, because it is not comparing queryset results, just the SQL queries itself.
Compatible with Python 2.7/3.5 and Django 1.8–1.10.
An unusual project, mypy-django is an implementation of the PEP-484 spec for the built-in Django components. Basically, if you care about static type checking, and you don’t mind using something experimental to help you, then you’ll care about this.
If you’ve never heard of this, and you’re wondering why we’re talking about static types in Python, then this is worth you reading about at least.
Compatible with Python 3.5+ and Django 1.10.
Want to gather statistics about your own models, but don’t want to rely on a third-party service? That’s what this does.
Through generic keys, If you want to do charts, reports, etc. for time series data, then this packages helps you to (1) create queries to extract that info and (2) handle the storage aspect for you.
Very important note: it will not provide you will a recurring task schedule, so don’t configure all this and wonder why your data isn’t getting recorded. You’ll need to run the queries inside of celery or something like it.
Compatibility seems a bit unclear. Python 2.7 and Django 1.9-1.10 are being tested, but it seems like they intend to test Python 3.4 as well, except their tests are misconfigured.
Selection Criteria for this List
Last time, I just derived my list from this query on Github for projects started this year. Basically, I’m doing by the most popular stars first, and after that, I was primarily interested in code bases that were things that you could add to a Django project to provide either drop-in functionality or enable you to build features more easily.
Consequently, I eliminated anything that (1) wasn’t primarily python code, (2) was really just a starter template, and (3) was not English, because I can’t read Chinese or German or Spanish (you get the idea).
Keeping those existing criteria in mind, I added another level of filtering for this list. I included (4) no service integrations or (5) projects that presuppose usage of another large package(s).
What do I mean by service integrations? Basically, if the project calls an API, it’s service integration to me. So that’s things like django-zappa (which is now just zappa by the way) that lets you run django on aws lambda or django-stackoverflow that auto searches your debug error on Stackoverflow.
What do I mean presupposing using another large package? Basically, if in order to use this package, you need to go configure something else first like Django Channels (aka channels) or Django Rest Framework (aka DRF) or Django CMS. All those projects have their own little ecosystems . So for example, drf-url-filters is a great library that allows you to cleanly implement validations of the url queries, but it assumes you’re using Django Rest Framework, which is definitely not true for everyone.
One thing I’d like to be super clear on: by excluding those things above from my list, I’m not saying those things lack value, but they ultimately this list could be easily dominated by those things, and I’d really like this list to be useful for Django specifically, not Django plus something else. That said, I may make separate lists in the future for the things I’ve excluded for right now from this one.