Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Join me in supporting the Ada Initiative
I believe deeply in the importance of gender equality, yet I work in open source, a community with shockingly few women. The Ada Initiative is working together with people like me to bring more women into open source - and we’re succeeding. That’s why I’m challenging the Python community to help me raise $10,000: I’ll match any donations from the Python community to the Ada Initiative up to a maximum of $5,000. -
Django Round-Up #7
This week Kenneth and Brandon are joined by Julia Elman! -
Catching up
For a while now I’ve been pretty embarrassed by this site. Not by the visual design, or the functionality (though some bits have been lost along the way, for reasons that will become obvious in a moment), but by the fact that it was old. As in, over five years old. It was running on a bunch of ancient code that I’d written a long, long time ago, on an ancient Subversion checkout ... Read full entry -
Catching up
For a while now I’ve been pretty embarrassed by this site. Not by the visual design, or the functionality (though some bits have been lost along the way, for reasons that will become obvious in a moment), but by the fact that it was old. As in, over five years old. It was running on a bunch of ancient code that I’d written a long, long time ago, on an ancient Subversion checkout of Django ... Read full entry -
Django and pip wheel
Just a quick heads-up: older Django versions don't work properly if installed via wheel. It's fixed in 1.6 but it's not final yet (right now it's in beta). Edit: Django 1.5.2 has the fix backported from 1.6. Apparently the older versions of Django list the package data files under the data_files setup.py option and wheel follows the spec to the letter (installs data_files in sys.prefix) while setuptools does not (it treats relative data_files just like package_data entries). If you switched to wheels already you can fix the template loading with something like this: import sys import os from django.template.base import TemplateDoesNotExist from django.template.loader import BaseLoader from django.conf import settings class SysPrefixLoader(BaseLoader): is_usable = True def load_template_source(self, template_name, template_dirs=None): pkg_name = 'templates/' + template_name for app in settings.INSTALLED_APPS: try: return open( os.path.join( sys.prefix, os.path.join(*app.split('.')), pkg_name ), 'rb' ).read().decode(settings.FILE_CHARSET), 'sysprefix:%s:%s' % (app, pkg_name) except Exception: pass raise TemplateDoesNotExist(template_name) And just add module.SysPrefixLoader to TEMPLATE_LOADERS in the settings. For the staticfiles, use this finder: import sys import os from django.contrib.staticfiles.finders import AppDirectoriesFinder, FileSystemStorage class SysPrefixAppStaticStorage(FileSystemStorage): def __init__(self, app, *args, **kwargs): location = os.path.join( sys.prefix, os.path.join(*app.split('.')), 'static' ) super(SysPrefixAppStaticStorage, self).__init__(location, *args, **kwargs) class SysPrefixAppDirectoriesFinder(AppDirectoriesFinder): storage_class = SysPrefixAppStaticStorage And add module.SysPrefixAppDirectoriesFinder to STATICFILES_FINDERS in the … -
Django and pip wheel
Just a quick heads-up: older Django versions don't work properly if installed via wheel. It's fixed in 1.6 but it's not final yet (right now it's in beta). Edit: Django 1.5.2 has the fix backported from 1.6. Apparently the older versions of Django list the package data files under the data_files setup.py option and wheel follows the spec to the letter (installs data_files in sys.prefix) while setuptools does not (it treats relative data_files just like package_data entries). If you switched to wheels already you can fix the template loading with something like this: import sys import os from django.template.base import TemplateDoesNotExist from django.template.loader import BaseLoader from django.conf import settings class SysPrefixLoader(BaseLoader): is_usable = True def load_template_source(self, template_name, template_dirs=None): pkg_name = 'templates/' + template_name for app in settings.INSTALLED_APPS: try: return open( os.path.join( sys.prefix, os.path.join(*app.split('.')), pkg_name ), 'rb' ).read().decode(settings.FILE_CHARSET), 'sysprefix:%s:%s' % (app, pkg_name) except Exception: pass raise TemplateDoesNotExist(template_name) And just add module.SysPrefixLoader to TEMPLATE_LOADERS in the settings. For the staticfiles, use this finder: import sys import os from django import VERSION from django.contrib.staticfiles.finders import AppDirectoriesFinder, AppStaticStorage class SysPrefixStorage(AppStaticStorage): def __init__(self, app, *args, **kwargs): self.app_module = app if self.app_module == 'django.contrib.admin' and VERSION < (1, 4): self.prefix = 'admin' self.source_dir = 'media' location … -
Django Extensions 1.2.0
Django-Extensions version 1.2.0 is out now ! :) ChangeLog: More Python 3 support BACKWARDS COMPATIBILITY: Fixes to the UUID field might break backwards compatibility FEATURE: hook in dumpscript to control execution during run_import FEATURE: add --prof-file option to runprofileserver FEATURE: provide configurable way to obtain Keyczar class FEATURE: IPv6 and FQDN address support in runserver_plus FEATURE: runserver_plus setting for default address/port in settings.py FEATURE: added trvis status image FIX: JSONField did not allow empty list as default value FIX: support Django 1.5 swappable User model FIX: runserver_plus to serve static files correctly FIX: make spatialite work with reset_db FIX: sqldiff missing varchar size under PostGreSQL FIX: removed fallback uuid module FIX: sqlcreate use client hostname not database server hostname for grant FIX: graphmodels version comparison for 0.36 work around -
A Plan Comes Together
Long, hard days of coding, shuffling and teasing Oracle finally come to a close - or do they? I'm very pleased to report that, just before this blog post was published, we merged my schema-alteration branch into Django. It's been a long road, and I'd like to thank everyone who's helped me, especially those who backed my Kickstarter and my fellow core developers, all of whom have been invaluable. This isn't the end of my work, though; it's just the end of the first phase. Migrations are functional but not complete, and the schema backends are passing all of their tests but will still have a few bugs. What next? The next step is twofold; working on improving the documentation (there's still large gaps in the reference documentation), while also adding some missing features, including: Migration squashing. The underlying framework for this in place but the user-facing commands aren't written yet. More Operations, including ones for custom raw SQL and custom Python code (for more complex manipulations) Better merge detection: Currently it just errors, while instead it should be able to resolve some merges automatically. Support for out-of-transaction operations, like CREATE INDEX CONCURRENTLY on PostgreSQL. This will require a little … -
Keep that module out!
Keep that module out! We usually include a local_settings.py file in our Django projects. We use the file whenever some Django settings need to be tweaked according to the environment or specific requirements of individual developers. It was a challenge to find a good way to exclude that file from being installed in production. Read more... -
Writing thread-safe django - get_or_create
In this blog post, we'll discuss thread-safety, why it's important and how to write thread-safe django code, especially for bulk operations like management commands. We'll take a simple example - get or create. Thread-safety: Thread-safety means that our code can be run in multiple threads and behave as expected. The reason that code can be unsafe with regard to threads is because we'll be manipulating shared memory (e.g. database) from the threads and there's a chance of a race-condition which will produce unexpected results. To avoid this, we have the option of using read-write locks, transactions etc. We'll look at some simple examples and try to understand these options. The usual way: Let's consider a management command that syncs data from another source (e.g. API, remote database etc.. The correct way to do this would be to use the built-in django utility - get_or_create: Update: Updated the command to run each arg in a thread class MyThread(Thread): def __init__(self, my_id): super(MyThread, self).__init__(name=my_id) self.my_id = my_id def run(self): instance, created = MyModel.objects.get_or_create(my_id=my_id) print '%s %s' % (instance.id, created) instance.delete() return class Command(BaseCommand): args = '<my_id my_id ...>' help = 'Get or create instace of mymodel with my_id' def handle(self, *args, **options): … -
Django Round-Up #6
This week Kenneth and Brandon are joined by Russell Keith-Magee! -
Django i18n
What does i18n mean? i18n = i followed by 18 letters followed by n = internationalization That is it, just a short hand. It isn't the name of standard governmental or otherwise. When I watched the first videos about Django many years ago, they declared that Django had great internationalization support including a Welsh translation. It sounded great and I wanted to try to use it, but I was never involved in a project that really needed it, until now! At Thalmic Labs we were able to translate the company website into German and Korean in a matter of weeks, the most time was devoted to getting the translations done, very little was figuring out i18n in Django. It was only a few hours of hitting my head against the wall. Here is a bit of what I learned along the way. Hopefully it helps you. Resources First watch this excellent talk by Jacob Burch. He helps to fill in some of the gaps from the i18n documentation which you should also have a look at. Definitely grab Jacob's version of poxx, you won't need it in production or on staging so you can just install it locally: pip install … -
cookiecutter: Project Templates Made Easy
Yesterday, Jeff Knupp wrote an amazing how-to article called "Open Sourcing a Python Project the Right Way". While I was reading it, I was rather pleased by just how close it is to my own practices. Considering Jeff's amazing Writing Idiomatic Python, it meant I was on the right track. The downside, of course, is implementation. Creating reusable Python packages has always been annoying. There are no defined/maintained best practices (especially for setup.py), so you end up cutting and pasting hacky, poorly understood, often legacy code from one project to the other. Some of it does nothing and some of it fails catastrophically on Python 3. There's a term for this sort of behavior, and it's called Cargo Cult programming. Fortunately, while I was ranting and Jeff (and Hynek Schlawack) was writing, someone was making cookiecutter. cookiecutter does one thing and it does it well What cookiecutter does is make creating and maintaining project templates easy and intuitive. This allow developers of all languages (not just Python) the ability to break free from cargo-cult configuration and follow patterns dictated by the experts who present their own cookiecutter templates. So if you don't like how the author of cookiecutter's creates her … -
Cookiecutter: Project Templates Made Easy
Yesterday, Jeff Knupp wrote an amazing how-to article called "Open Sourcing a Python Project the Right Way". While I was reading it, I was rather pleased by just how close it is to my own practices. Considering Jeff's amazing Writing Idiomatic Python, it meant I was on the right track. The downside, of course, is implementation. Creating reusable Python packages has always been annoying. There are no defined/maintained best practices (especially for setup.py), so you end up cutting and pasting hacky, poorly understood, often legacy code from one project to the other. Some of it does nothing and some of it fails catastrophically on Python 3. There's a term for this sort of behavior, and it's called Cargo Cult programming. Fortunately, while I was ranting and Jeff (and Hynek Schlawack) was writing, someone was making cookiecutter. cookiecutter does one thing and it does it well What cookiecutter does is make creating and maintaining project templates easy and intuitive. This allow developers of all languages (not just Python) the ability to break free from cargo-cult configuration and follow patterns dictated by the experts who present their own cookiecutter templates. So if you don't like how the author of cookiecutter's creates her … -
Raspberry IO open sourced
Back in March, at PyCon 2013, the PSF provided each attendee with a Raspberry Pi, a tiny credit-card sized computer meant to be paired with the Python programming language. The power and portability of the Raspberry Pi has stimulated an explosion of interest among hobbyists and educators. Their uses seem to be limited only by our collective imagination. Along with that generous gift, the PSF contracted with Caktus to help tap into this collective imagination. Raspberry IO is a site dedicated to Python and Raspberry Pi enthusiasts. The goal of the site is to serve as a friendly place where anyone can learn and teach about using Python with a Raspberry Pi. We are proud to announce that Raspberry IO is now an open source project. We've written tests and documentation to help you get started and contribute your ideas to the site. Please create an issue at the github repository. We're excited about the possibilities for a site like this in the hands of the Raspberry Pi and Python communities. If you have an interesting Raspberry Pi project, then we'd love for you to tell us about it! Razzy welcomes you! -
Raspberry IO Open Sourced
Back in March, at PyCon 2013, the PSF provided each attendee with a Raspberry Pi, a tiny credit-card sized computer meant to be paired with the Python programming language. The power and portability of the Raspberry Pi has stimulated an explosion of interest among hobbyists and educators. Their uses seem to be limited only by our collective imagination. -
The state of Django and Ruby on Rails - one year later
Back in 2012 I wrote a post why my preferred choice for projects I realize with Blaze IT is Django and not Ruby on Rails. Since then it got a lot of attention and is still linked in some discussions and tweets today. People asked me for an update and if it is still relevant, so here we go. Before we start let me clarify two things: Both frameworks are a solid choice. If you cite this or my last post as an "OMG look at these arguments, $foo is clearly superior" source you did not understand the intention and arguments very well. You will get stuff done with both frameworks and your app will be fully functional and working. The choice is basically arguing on a pretty high level of comfort and the differences are pretty small (but still existing) - so one framework can beat the other in certain circumstances. It is a situational and personal decision, not an universal truth. A framework will not magically fix your existing project or build your app for you. It is one potential tool in your toolbox. If you are only building an API for a mobile app it can be … -
django-sphinxdoc 1.2
After more than a year, there is finally a new version of django-sphinxdoc available. Django-sphinxdoc is a Django app that allows you to integrate documentation written with Sphinx into your site. You can also search the documentation using Haystack. The new version adds internationalization support as well as Spanish and Basque localizations. It uses class-based views now and is compatible with Haystack >= 2.1. Thanks to Mike Shantz, Josiah Klassen, Andres Riancho and Ales Zabala Alava for their contributions. Unfortunately, I currently don’t have very much time to keep improving this app. So any contribution that solves an issue or adds a new feature is very welcome. -
Routing and Prepping
Old South bugs and nemeses get eliminated, multi-database support might finally exist, and the merge is in sight. It's been a slightly slower pace of work the last few weeks because of a friend's wedding on the wonderful island of Madeira (you can read my Trip Notes if you want to know more), but there were still a few notable changes. Routers The thing I'm most excited about is database router support for migrations. South is especially bad at multi-database migrations, supporting only the bare minimum to even function, and so I wanted to improve that state of affairs for django.db.migrations. Since syncdb had just been deprecated in my branch, the allow_syncdb method on database routers seemed a little out of place. The idea was still sound - say which models can be installed in each database - but the name and usage needed adapting. Thus, it's been renamed to allow_migrate, and the migration operations have been updated to respect it. Because the new codebase operates on models (rather than tables, like South does), it can just call the router inside every operation, see what it's allowed to do, and just do it. There's a few caveats, of course; you … -
Migrating to a Custom User Model in Django
.. |--| unicode:: U+2013 .. en dash .. |---| unicode:: U+2014 .. em dash, trimming surrounding whitespace :trim: The new `custom user model configuration `_ that arrived in Django makes it relatively straightforward to swap in your own model for the Django user model. In most cases, Django's built-in ``User`` model works just fine, but there are times when certain limitations (such as the `length of the email field `_) require a custom user model to be installed. If you're starting out with a custom user model, setup and configuration are relatively straightforward, but if you need to migrate an existing legacy project (e.g., one that started out in Django 1.4 or earlier), there are a few gotchas that you might run into. We did this recently for one of our larger, long-term client projects at Caktus, and here's an outline of how we'd recommend tackling this issue: 1. First, assess any third party apps that you use to make sure they either don't have any references to the Django's ``User`` model, or if they do, that they use Django's generic methods for `referencing the user model `_. 2. Next, do the same thing for your own project. Go through … -
Migrating to a Custom User Model in Django
UPDATE: Read a newer blog post on this topic. The new custom user model configuration that arrived in Django makes it relatively straightforward to swap in your own model for the Django user model. In most cases, Django's built-in User model works just fine, but there are times when certain limitations (such as the length of the email field) require a custom user model to be installed. If you're starting out with a custom user model, setup and configuration are relatively straightforward, but if you need to migrate an existing legacy project (e.g., one that started out in Django 1.4 or earlier), there are a few gotchas that you might run into. We did this recently for one of our larger, long-term client projects at Caktus, and here's an outline of how we'd recommend tackling this issue: -
Combining RFID, NFC and QRCodes with django-oscar online shop
You can write a lot of tutorials about making web apps. So to make something different lets talk about using some hardware and combine it with a shop. I'll show how to use RFID, NFC and QRCodes with a django-oscar based shop. RFID is close range radio communication. It can be used in many places like in logistics to track packages, or for identification cards. You need a RFID reader and a RFID tag with the radio device. The tag may be a sticker, a clip or something else (a lot of shape and sizes). The the tag is put close to the reader the electromagnetic field induces current in the tag that powers the radio devices. It sends back data to the reader. In most simple RFID standards it will be just unique identification number. In writable tags it may be an URL pointing to the product on the website. -
An easier way to change Django cache backend between test cases
An easier way to change Django cache backend between test cases In Changing Django cache backend between test cases I showed how to use the Mock library to activate a different cache backend for individual tests. In the comments for that article, Diederik van der Boor pointed out that the same effect can be achieved in a cleaner way by using a custom “proxy” cache backend. I took the challenge and created a proxy cache backend and a decorator for switching the effective backend on the fly. First, let’s look at how to use this beast. Activate the proxy backend in the settings.py you use for running tests: CACHES = { 'default': { 'BACKEND': 'cache_switch.CacheSwitch', 'LOCATION': 'dummy://' } } Thanks to a trick adapted from the Mock library, the decorator can be used to decorate test case classes, test methods and functions. It also works as a context manager. Here are examples of each of those use cases: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21from cache_switch import cache_switch from django.test import TestCase @cache_switch('locmem://') def test_decorated_function_runs_with_locmem_cache(): # test code class MethodDecoratorTestCase(TestCase): @cache_switch('locmem://') def test_decorated_method_runs_with_locmem_cache(self): # test code … -
Tracking CPC Results in Django
Like many startups, I use CPC ads to attract attention to WhisperGifts. I bid a set fee per click for particular search words on Google, and for ads shown to my target demographic on Facebook. I wanted to track an individual signup to their source CPC campaign, so put together a really quick bit of Django middleware to help me out. -
Tracking CPC Results in Django
Like many startups, I use CPC ads to attract attention to WhisperGifts. I bid a set fee per click for particular search words on Google, and for ads shown to my target demographic on Facebook. I wanted to track an individual signup to their source CPC campaign, so put together a really quick bit of Django middleware to help me out. All I do is stash the value of utm_campaign (set by Google or Facebook) into a cookie called wgcookie. class CampaignMiddleware(object): def process_response(self, request, response): from registry.models import Campaign if 'utm_campaign' in request.GET.keys(): if 'wgcampaign' not in request.COOKIES.keys(): # add campaign cookie c = request.GET.get('utm_campaign', None) response.set_signed_cookie('wgcampaign', c, max_age=31536000, httponly=True) return response At signup time, I read out the cookie into the users table: try: campaign_code = request.get_signed_cookie('wgcampaign', None) except: campaign_code = None user.campaign_code = campaign_code Simple! I've now got the capability to track actual revenue by campaign source - a very handy tool to identify which campaigns might warrant higher or lower spending. I'm aware this isn't rocket science, but I figured it's worthwhile sharing - it makes more sense to me to track these things directly in my own database, than to try and match data from …
