17 ms·
My essential django package list
- eugeneionesco 9y agoYour site is full of juicy content, thanks!
- travelton 9y agoVery 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 9y agoHello, 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 :)
- chrxr 9y agoGreat list, and thanks for giving Wagtail a shout-out! Your work on it back in its early days is still very much appreciated.
- spapas82 9y agoThank you very much! Both contributing and working (using it as a CMS in various projects) with Wagtail were an absolute joy!
- andykish 9y agoSince this Django post made it to the front page, if anyone with expertise with Wagtail is looking for contract work, reach out to my email in my profile! In particular, we're looking to implement StreamField in our CMS, plus exposing some "templating" functionality to end users.
- philipov 9y agoCould someone please concisely describe if there is a use-case where Django offers utility above what Flask can provide?
- KekDemaga 9y agoI too am curious. I had trouble getting started with Django but once I tired Flask everything seemed to make sense.
- davidscolgan 9y agoA definite downside of Django is learning curve. I'd argue Django is harder at first but easier in the long term.
- charred_toast 9y agoExactly; it takes time to learn the thing—it's huge compared to Flask. The documentation is killer though. I've been learning django for at least a few years now. I try not to rush, I know I'll figure it out eventually is basically my philosophy.
- davidscolgan 9y agoDjango definitely has top tier documentation. I'd recommend first reading the official tutorial, then trying to make something with it and referring to the different sections as needed. For people wanting to go to the next level Two Scoops of Django is a fantastic book on best practices, and even more opinionated than Django, which I consider to be a great thing.
- speg 9y agoBuilt 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.
- orf 9y agoGreat 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 9y agoHello 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.
- thraxil 9y agoCool. 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 9y agoWould 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 9y agoI'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.
- thraxil 9y agoYeah, Wagtail documentation is a bit scattered. That's probably one of the larger issues I've run into when using it. Overall, I like it though. As much as it seems like a deviation from Django patterns, I actually found it easier to integrate Wagtail into existing Django projects than others like django-cms. I find that I typically end up with a "CMS" part of the app that exists fairly independently from the rest. Making foreign-key references to models outside Wagtail isn't too hard, and it integrates fine with the main site templates. Otherwise, I find that I don't often need to do much interaction between the Wagtail parts and other parts (which would be hard). I haven't really done a lot of complicated things with Wagtail though.
- charred_toast 9y agoGreat reference. Thank you, spapas82. Bookmarked!
- polote 9y agoThis 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 9y agohonestly? 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 9y agoI 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 / { ... }.
- lastofus 9y agoThe 2 that come to mind are DRF and django-webpack-loader. The webpack loader is great if you use webpack, and want to use the Django template language to render your index.html. Sometimes server side rendering of initial data is nicer than having to send all initial data down w/ AJAX calls.
- Posibyte 9y agoI 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 9y agoThank you very much for your kind words!
- katelynsills 9y agoGreat list! I noticed Tastypie wasn't included. I've really liked it, but are there reasons I shouldn't be using it?
- cname 9y agoIt looks like the author prefers Django REST Framework (DRF) instead of Tastypie. I can't compare them on their technical merits as I've never used Tastypie, but I do know that DRF is actively developed and has some kind of backing. DRF is one of my "always on" Django packages.
- spapas82 9y agoActually, I remember some years back that when I needed a REST API for a project I started with django-tastypie because back then (circa 2012) was more popular than DRF. Unfortunately, I did not have a good experience with it (too long to release a new version to support new django version) so I switched over to DRF and hasn't look back since. I'm not really familiar with the status of django-tastypie right now but from what I see from the other comments it probably is better than tastypie. Also please notice that I wanted to include one of each kind of package in the list since it's the actual list of packages I'm going to use when I need a feature - so there's no reason to include both DRF and tastypie (yes, django-simple-history and django-reversion were both included but as I explain in the article they have different usage models).
- mycelium 9y agoIn 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 9y agoHaving 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.
- ris 9y agoDjango 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 9y agoI 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!
- npolet 9y agoGreat 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 9y agoHello, 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-watchify/ https://spapas.github.io/2015/05/27/using-browserify-watchif... 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).
- collyw 9y agoIt 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 9y agoHello, 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!
- legostormtroopr 9y agoNumber 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 9y agoHello, 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.
- disillusioned1 9y agoGreat resource! Perhaps make it easier to find on your site by adding it to your "Django" category?
- spapas82 9y agoThank 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!