Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Why you should run for the DSF Board, and my goals for the DSF in 2025
Applications are open for the 2025 Django Software Foundation Board of Directors – you can apply until October 25th. So, in this post I’ll do two things: try to convince you to run for the board, and document my goals and priorities for 2025. -
Epic Debugging, Hilarious Outcome - Building SaaS #205
In this episode, I dug into an issue with sign up. What I thought was going to be a minor issue to fix turned into a massively intense debugging session. We ended up going very deep with the django-allauth package to understand what was going on. -
Epic Debugging, Hilarious Outcome - Building SaaS #205
In this episode, I dug into an issue with sign up. What I thought was going to be a minor issue to fix turned into a massively intense debugging session. We ended up going very deep with the django-allauth package to understand what was going on. -
Getting RequestContext in Your Templates
Lately, we’ve been taking over projects from people who began building their first site in Django, but either got in over their head or just found they didn’t have the time to continue. As I review the existing code, the first issue I typically see is using the render_to_response shortcut without including the RequestContext, preventing context processors from being used in the templates. The standard symptom is when people can’t access MEDIA_URL in their templates. Here are a few ways to add RequestContext to your templates. Option #1: Adding RequestContext to render_to_response The Django documentation recommends passing RequestContext as an argument to render_to_response like this: from django.shortcuts import render_to_responsefrom django.template import RequestContextdef my_view(request): # View code here... return render_to_response('my_template.html', my_data_dictionary, context_instance=RequestContext(request)) This works, but as you can see, it adds a fair amount of repetitive code to your views. Option #2: Wrapper for render_to_response Don’t repeat yourself. Create a wrapper like this, courtesy of Django Snippet #3 from django.shortcuts import render_to_responsefrom django.template import RequestContextdef render_response(req, *args, **kwargs): kwargs['context_instance'] = RequestContext(req) return render_to_response(*args, **kwargs) Option #3: Use Generic Views Django’s generic views include RequestContext by default. Although the docs show them being used in urls.py, you can just as easily use … -
Managing Django Projects on Your Server with Style
This article is outdated, you’ll find an updated article here. A friend is in the process of setting up a new slice at everbody’s favorite VPS provider Slicehost and asked for some advice. I use MySQL, Nginx & Apache/mod_wsgi on Ubuntu to serve Django. I think Slicehost’s Articles are awesome and a great place to get help you get everything installed and running, so for this article, I’ll focus on some personal preferences regarding directory structure and repo management. One of the biggest difficulties I’ve had to tackle lately is the rapid progress of Django. I have a number of client sites hosted on my slice and have had to freeze them at certain times when backwards incompatible changes come along. My original approach made this really messy, because I only accounted for having one copy of any given third party repo, symlinked from /usr/local/src to my Python site-packages directory. My new approach takes advantage of being able to set your PYTHONPATH at runtime. My directory structure looks like this: |-django |--projects |---domain1.com |---domain2.com |---domain3.com Each site has the following structure: |-domain1.com |--apache |---django.wsgi |--django |--domain1_project |---__init__.py |---app1 |---app2 |---manage.py |---settings.py |---static |---templates |---urls.py |--third_party_repo1 |--third_party_repo2 Just drop domain1.com in … -
Building a Community Site with Django in 40 Hours or Less
All the recent hub bub about 1 week and 1 day application development, motivated me to see how quickly I could launch a website for myself. I, like many developers, struggle with building and releasing personal sites. Ask a web developer and they’re likely to tell you about a couple of sites they started and never finished. Time is always an issue, but the bigger problems are striving for perfection prior to launch and always holding out for that one “killer” feature. As time goes on, interest in the project wanes until it finally gets shelved. The Plan Prior to development, I set a few goals for myself: Launching quickly was priority number one. I set a goal of 3 days. Use as much existing code as possible. Even if it wasn’t a perfect fit, if it was functional, use it. Optimize later. Stop scope/feature creep at all costs. Stay focused. I’m easily sidetracked when working on personal projects. Notice “building a killer website” was not one of the goals. This project was strictly a speed challenge a’la Django Dash. The Idea I wanted to build a site cataloging mountain bike trails complete with full GPS data. I decided not … -
Django Newforms Admin Merged to Trunk
This was a huge feat. Congrats guys! 1.0 here we come. -
Django for Hire
Lincoln Loop has been in “head down” mode for the last couple months. In addition to being knee deep in client projects, we have grown from a one-man development studio to a full-fledged Django development shop/consultancy. We are proud to announce that Lincoln Loop is the first (that we know of) company focusing solely on Django application development. Our development team is currently five strong and oozing with talent. Each member contributes to the community in blog posts or open source add-ons; a few of us have contributed code to Django itself. More on our dev team in the near future. We went through the typical growing pains during the transition, but the kinks are worked out and we can officially say that we are open for business. Django projects big and small, send them our way. Our devs can handle nearly anything. New Django projects based on your specs Existing projects when your developer doesn’t have the time, doesn’t have the expertise or just skipped out on you Scaling up your existing development team for large feature pushes Ellington customization You name it, if it is Django related, we can probably help. Don’t be shy, drop us a line. -
Getting RequestContext in Your Templates
Lately, we’ve been taking over projects from people who began building their first site in Django, but either got in over their head or just found they didn’t have the time to continue. As I review the existing code, the first issue I typically see is using the render_to_response shortcut without including the RequestContext, preventing context processors from being used in the templates. The standard symptom is when people can’t access MEDIA_URL in their templates. Here are a few ways to add RequestContext to your templates. Option #1: Adding RequestContext to render_to_response The Django documentation recommends passing RequestContext as an argument to render_to_response like this: from django.shortcuts import render_to_responsefrom django.template import RequestContextdef my_view(request): # View code here... return render_to_response('my_template.html', my_data_dictionary, context_instance=RequestContext(request)) This works, but as you can see, it adds a fair amount of repetitive code to your views. Option #2: Wrapper for render_to_response Don’t repeat yourself. Create a wrapper like this, courtesy of Django Snippet #3 from django.shortcuts import render_to_responsefrom django.template import RequestContextdef render_response(req, *args, **kwargs): kwargs['context_instance'] = RequestContext(req) return render_to_response(*args, **kwargs) Option #3: Use Generic Views Django’s generic views include RequestContext by default. Although the docs show them being used in urls.py, you can just as easily use … -
Managing Django Projects on Your Server with Style
This article is outdated, you’ll find an updated article here. A friend is in the process of setting up a new slice at everbody’s favorite VPS provider Slicehost and asked for some advice. I use MySQL, Nginx & Apache/mod_wsgi on Ubuntu to serve Django. I think Slicehost’s Articles are awesome and a great place to get help you get everything installed and running, so for this article, I’ll focus on some personal preferences regarding directory structure and repo management. One of the biggest difficulties I’ve had to tackle lately is the rapid progress of Django. I have a number of client sites hosted on my slice and have had to freeze them at certain times when backwards incompatible changes come along. My original approach made this really messy, because I only accounted for having one copy of any given third party repo, symlinked from /usr/local/src to my Python site-packages directory. My new approach takes advantage of being able to set your PYTHONPATH at runtime. My directory structure looks like this: |-django |--projects |---domain1.com |---domain2.com |---domain3.com Each site has the following structure: |-domain1.com |--apache |---django.wsgi |--django |--domain1_project |---__init__.py |---app1 |---app2 |---manage.py |---settings.py |---static |---templates |---urls.py |--third_party_repo1 |--third_party_repo2 Just drop domain1.com in … -
Building a Community Site with Django in 40 Hours or Less
All the recent hub bub about 1 week and 1 day application development, motivated me to see how quickly I could launch a website for myself. I, like many developers, struggle with building and releasing personal sites. Ask a web developer and they’re likely to tell you about a couple of sites they started and never finished. Time is always an issue, but the bigger problems are striving for perfection prior to launch and always holding out for that one “killer” feature. As time goes on, interest in the project wanes until it finally gets shelved. The Plan Prior to development, I set a few goals for myself: Launching quickly was priority number one. I set a goal of 3 days. Use as much existing code as possible. Even if it wasn’t a perfect fit, if it was functional, use it. Optimize later. Stop scope/feature creep at all costs. Stay focused. I’m easily sidetracked when working on personal projects. Notice “building a killer website” was not one of the goals. This project was strictly a speed challenge a’la Django Dash. The Idea I wanted to build a site cataloging mountain bike trails complete with full GPS data. I decided not … -
Django Newforms Admin Merged to Trunk
This was a huge feat. Congrats guys! 1.0 here we come. -
Django for Hire
Lincoln Loop has been in “head down” mode for the last couple months. In addition to being knee deep in client projects, we have grown from a one-man development studio to a full-fledged Django development shop/consultancy. We are proud to announce that Lincoln Loop is the first (that we know of) company focusing solely on Django application development. Our development team is currently five strong and oozing with talent. Each member contributes to the community in blog posts or open source add-ons; a few of us have contributed code to Django itself. More on our dev team in the near future. We went through the typical growing pains during the transition, but the kinks are worked out and we can officially say that we are open for business. Django projects big and small, send them our way. Our devs can handle nearly anything. New Django projects based on your specs Existing projects when your developer doesn’t have the time, doesn’t have the expertise or just skipped out on you Scaling up your existing development team for large feature pushes Ellington customization You name it, if it is Django related, we can probably help. Don’t be shy, drop us a line. -
On Static Media and Django
We all know not to serve static media (images, CSS, Javascript, etc.) in production directly from Django. Thankfully, Django gives us some nice settings like MEDIA_URL and MEDIA_ROOT to make serving them a lot less painless. Lately, however, I’ve come to realize that these settings shouldn’t really apply to all static media. Not All Static Media Is Created Equal Static media really comes in two flavors. Media that is part of your site like your stylesheets and user generated media or files that are uploaded to the site once it is live. We don’t want to serve all this media from the same place for a couple of reasons: Our source checkouts shouldn’t be crufted up by stuff our users are uploading User generated content and source code should live in two different places on the filesystem We could fix the first problem with some .gitignore, but that doesn’t solve the filesystem issue. Solution: Segregate Your Static Files The answer is to segregate your static files. Django already does this with ADMIN_MEDIA_PREFIX. We use two additional settings in our Django projects, STATIC_URL and STATIC_ROOT. This lets us put user generated content in MEDIA_ROOT outside our project while still serving STATIC_ROOT … -
Serving Django Projects (Revisited)
After reading the comments on my last post on the subject, I realized there was definitely some room for improvement in my strategy. This is take two of the original post. Problems My original strategy had a couple of downfalls: Poisoning the Python Path I was adding directories to the Python Path that weren’t Python. This raised the chance of namespace collision and just wasn’t a very clean way to do things. No project source repository I was still storing all my source files in one big folder. Tracking which project is using what was more difficult than it needed to be. Solutions The first step to recovery was forgetting about sharing libraries between projects altogether. In theory it sounds great, in practice it was cumbersome to manage. My directory structure now looks like this: |-domain1.com |--apache |---django.wsgi |--src |---domain1_project_src |---third_party_repo1 |---third_party_repo2 This is much cleaner and allows for simple control over the versioning on third party repositories. For source with stable <span class="caps">API</span>s, like Django 1.0, I still place it in <tt>/usr/local/src</tt>, allowing me to update all sites using the library in one go without worrying about breakage. Virtualenv is Your New Best Friend As recommended in the comments … -
On Static Media and Django
We all know not to serve static media (images, CSS, Javascript, etc.) in production directly from Django. Thankfully, Django gives us some nice settings like MEDIA_URL and MEDIA_ROOT to make serving them a lot less painless. Lately, however, I’ve come to realize that these settings shouldn’t really apply to all static media. Not All Static Media Is Created Equal Static media really comes in two flavors. Media that is part of your site like your stylesheets and user generated media or files that are uploaded to the site once it is live. We don’t want to serve all this media from the same place for a couple of reasons: Our source checkouts shouldn’t be crufted up by stuff our users are uploading User generated content and source code should live in two different places on the filesystem We could fix the first problem with some .gitignore, but that doesn’t solve the filesystem issue. Solution: Segregate Your Static Files The answer is to segregate your static files. Django already does this with ADMIN_MEDIA_PREFIX. We use two additional settings in our Django projects, STATIC_URL and STATIC_ROOT. This lets us put user generated content in MEDIA_ROOT outside our project while still serving STATIC_ROOT … -
Serving Django Projects (Revisited)
After reading the comments on my last post on the subject, I realized there was definitely some room for improvement in my strategy. This is take two of the original post. Problems My original strategy had a couple of downfalls: Poisoning the Python Path I was adding directories to the Python Path that weren’t Python. This raised the chance of namespace collision and just wasn’t a very clean way to do things. No project source repository I was still storing all my source files in one big folder. Tracking which project is using what was more difficult than it needed to be. Solutions The first step to recovery was forgetting about sharing libraries between projects altogether. In theory it sounds great, in practice it was cumbersome to manage. My directory structure now looks like this: |-domain1.com |--apache |---django.wsgi |--src |---domain1_project_src |---third_party_repo1 |---third_party_repo2 This is much cleaner and allows for simple control over the versioning on third party repositories. For source with stable <span class="caps">API</span>s, like Django 1.0, I still place it in <tt>/usr/local/src</tt>, allowing me to update all sites using the library in one go without worrying about breakage. Virtualenv is Your New Best Friend As recommended in the comments … -
Introduction to Gondola
Gondola is our content management system built on top of Django. I briefly showed it off during my DjangoCon Lightning Talk, but have been wanting to give it a proper screencast for a while. Here’s an introduction: A few common questions I don’t tackle in the screencast: Is this an open source project? As of right now, no. I do plan on spinning off a few bits as open source over time. In fact, the WYSIWYG editor is already on Google Code as django-admin-uploads. Unfortunately it hasn’t been synced up with our in-house code in a while and isn’t working on 1.0. We’ll get that updated at some point in the near future. How much will it cost? I haven’t settled on a pricing structure yet, but I want it to be affordable for small businesses. What version of Django are you running? 1.0 How’d you add all that stuff to the Django admin interface? It is really quite easy by just overriding a few of the default templates. I hope to write a blog post soon with more details. When can I get my hands on it? Soon. If you have a site you’re interested in putting on it … -
My Lightning Talk from DjangoCon 2008
DjangoCon was an amazing conference all around. I met some great people and learned a lot. I also had the opportunity to get up on stage and present some of the things I’ve been working on here. I was really nervous and after seeing how well prepared the presenters before me were, I had doubts about my plan to go on stage and wing it. I spoke about Trailmapping and Gondola the CMS I’ve been working on. Afterwards, I was blown away by the number of compliments I received. A few people told me they thought my talk was the best of the bunch which was really encouraging. To everyone that reached out, all I can say is thanks; it meant a lot. I’m inspired to carve out some more time to blog about the things I’m working on, specifically Django admin customization and jQuery. Well, it is now on YouTube for all to see. Skip forward to 18:50 if you just want to catch my talk and as I mention in the video, drop me a line or comment here if you’re interested in any of this stuff. Also, Trailmapping got a quick mention (32:22) during James Tauber’s Pinax … -
Introduction to Gondola
Gondola is our content management system built on top of Django. I briefly showed it off during my DjangoCon Lightning Talk, but have been wanting to give it a proper screencast for a while. Here’s an introduction: A few common questions I don’t tackle in the screencast: Is this an open source project? As of right now, no. I do plan on spinning off a few bits as open source over time. In fact, the WYSIWYG editor is already on Google Code as django-admin-uploads. Unfortunately it hasn’t been synced up with our in-house code in a while and isn’t working on 1.0. We’ll get that updated at some point in the near future. How much will it cost? I haven’t settled on a pricing structure yet, but I want it to be affordable for small businesses. What version of Django are you running? 1.0 How’d you add all that stuff to the Django admin interface? It is really quite easy by just overriding a few of the default templates. I hope to write a blog post soon with more details. When can I get my hands on it? Soon. If you have a site you’re interested in putting on it … -
My Lightning Talk from DjangoCon 2008
DjangoCon was an amazing conference all around. I met some great people and learned a lot. I also had the opportunity to get up on stage and present some of the things I’ve been working on here. I was really nervous and after seeing how well prepared the presenters before me were, I had doubts about my plan to go on stage and wing it. I spoke about Trailmapping and Gondola the CMS I’ve been working on. Afterwards, I was blown away by the number of compliments I received. A few people told me they thought my talk was the best of the bunch which was really encouraging. To everyone that reached out, all I can say is thanks; it meant a lot. I’m inspired to carve out some more time to blog about the things I’m working on, specifically Django admin customization and jQuery. Well, it is now on YouTube for all to see. Skip forward to 18:50 if you just want to catch my talk and as I mention in the video, drop me a line or comment here if you’re interested in any of this stuff. Also, Trailmapping got a quick mention (32:22) during James Tauber’s Pinax … -
Simple & Easy Deployment with Fabric and Virtualenv
In the process of prepping Gondola CMS for public consumption, we’ve grown from having a developer (me), to having a development team. One pain point that quickly arose was the amount of time it took for new developers to setup a local development environment. In addition to our source code, the project depends on nearly a dozen other Django apps and Python packages. Initially, we simply tracked the requirements in a text file, but it required a lot of manual work to get them downloaded and installed. Necessity is the Mother of Invention Of course, this problem has been tackled many, many times before1. As I looked into what was out there, my first thought was that most of the existing options were far too complex for our needs. If I didn’t grok a system after clicking around the docs for 10 minutes or so, I moved on. The tool I eventually decided on was Fabric. I was attracted to Fabric, primarily because I found it simple and easy to understand. Unfortunately, I didn’t find a lot of information on using it for local buildouts, so I forged ahead building my own. fab bootstrap Our needs were simple. I wanted … -
Simple & Easy Deployment with Fabric and Virtualenv
In the process of prepping Gondola CMS for public consumption, we’ve grown from having a developer (me), to having a development team. One pain point that quickly arose was the amount of time it took for new developers to setup a local development environment. In addition to our source code, the project depends on nearly a dozen other Django apps and Python packages. Initially, we simply tracked the requirements in a text file, but it required a lot of manual work to get them downloaded and installed. Necessity is the Mother of Invention Of course, this problem has been tackled many, many times before1. As I looked into what was out there, my first thought was that most of the existing options were far too complex for our needs. If I didn’t grok a system after clicking around the docs for 10 minutes or so, I moved on. The tool I eventually decided on was Fabric. I was attracted to Fabric, primarily because I found it simple and easy to understand. Unfortunately, I didn’t find a lot of information on using it for local buildouts, so I forged ahead building my own. fab bootstrap Our needs were simple. I wanted … -
Thibaud Colas - 2025 DSF Board Nominations
Thibaud on LinkedIn, on Mastodon Django on Mastodon, on LinkedIn2025 DSF Board NominationsDjango Forum Discussion of 2025 DSF Board ElectionsDSF Individual Members and Steering Council MembersTorchbox CTO and senior dev job offersWagtail high-profile users, newsletter, roadmapSponsorDjango Chat Podcast Sponsorship Information -
My Django wishlist explained
Recently Andy Miller - AKA nanorepublica posted in various media about missing Django batteries, including but not limited to this forum thread and articles series. He's not the only one, I have seen similar posts from several other people in my circles. Here I'll try to explaining my take on the original forum question
