Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django based startup – YouTellMe.nl
YouTellMe.nl is a completely Django based startup located in Amsterdam. We’re probably one of the largest Django projects in terms of codebase. Pretty soon the famous nextweb awards are coming up. (remember those guys which broke into Michael Arrington’s house?). And we need some love from the Django community. Lots of it. Pretty please nominate youtellme.nl for the next web! http://dsa.thenextweb.com/?lang=nl Good articles coming soon to offset the bad karma for this shameless plug ;) Update: A couple of stats about the current codebase. According to wc (including whitespace and comments) we currently have: Python: 3,363,188 characters, 87926 lines, 655 files Javascript: 940,536 characters, 24229 lines, 77 files Share and Enjoy: -
South 0.7 RC1
It's that time of the year again, when a new South release rears its well-refactored, database-independent head.If you've been following the development of South at all, you'll know that 0.7 has been quite a while in the making. I've been busy working away at a big code refactor, along with Simon Law, who has gained the title of "Knowing Too Much About Migrations". However, there are some user-facing changes as well, some quite significant. While my release notes go into some detail on what's new, the major changes include: New command names.The old startmigration was getting a little overloaded and wasn't too well-named, so it's been split into schemamigration and datamigration commands. No more issues with missing defaults. South realises you need a default for NOT NULL columns now, and prompts you if you forget to specify one as you're making the migration, instead of dying when you try to apply it. Django 1.2 and MultiDB support. As well as supporting the latest and greatest incarnation of the universe's best web framework, 0.7 also has some limited MultiDB support, in the form of a --database option (that works like the option of the same name on the new syncdb command … -
Django query analyzer
One of the things I wanted to work on at the DjangoSki sprints was a django query analyzer. The basic premise is that I want to create an easy way for users to experiment with and play with the ORM to produce the queries that they want. If you are new to Django, figuring out the ORM is one the first things you will need to tackle and it can be a little opaque. There's some ways to play with it at the shell, or use the debug toolbar, but these can be a little limited and unhelpful to newbies. The main interface would ideally be a series of options introspected from the model. Choose a model, choose a query manager, then add in multiple filter queries. This would not be able to capture everything and you'd always need an opt out clause of a text area where you can enter anything you want. This is pretty similar to the GUI's you'll get with most SQL servers, its just the Django ORM layer on top of it. Sadly I didn't get much chance apart from some time on Thursday afternoon. But a whole bunch of other people did including Stefan … -
Maintain Constants.py through Data Migration
This post will show you how to create a local_contants.py file using Django South. If you're not familiar with South, it's a data migration tool. Stated differently, it's a tool that helps keep your database changes current across different sandboxes and server environments. The reason you may want to have constants is when you have a type model instance that you want to reference in your code for decision logic. For example, you might display things differently if your contact method type ID is 1 (email) vs 2 (phone). Typically, you keep these in constants.py file. Although sometimes you can put this data in a fixture, for various reasons sometimes fixtures is not the ideal solution. The code below is designed to be run inside a migration to update your local_constants.py file with data that you just migrated. local_constants.py is a locally maintained file. This means, that like your local_settings.py, it should not be in the repo. For example: set_constant('/home/projects/sample/local_constants.py', 'STAMP_MW_ID', 42 , 'Set from sample.0007_add_constants.py') The constant searching could be improved, feel free to post enhancements! def set_constant(file, constant, value, comment = ''): ''' Search through file for the constant and either adds it to the end or updates … -
Configuring Nginx as a Pass Through Image Proxy
This post shows how to setup Nginx has a pass-through image proxy server. This is useful for local sandboxes, UAT and QA servers where you copy production database down to but don't want to copy all the user generated images to the non production environment. The problem You have a production database with lots of images uploaded by users. For example, NationalGeographic.com has over 11gb of user uploaded images. When you download a data dump of the production DB, it has links to all these images which you don't have. You either have to download and sync all the images locally every time you copy the database, live with broken images or point your static images to the prod server. Copying images locally is the brute force method and will work. If you have all day to sync up images. Pointing to the images in prod also works, but if you upload your own images to test functionality... You will not be able to see those new images. Solution Setup nginx to look for static images locally and if it doesn't find it, go to the production server and pull the image. This works nicely because you can upload images … -
2Ze.us Updates
There has been quite a bit of recent activity in my 2ze.us project since I first released it nearly a year ago. My intent was not to become a competitor with bit.ly, is.gd, or anyone else in the URL-shortening arena. I created the site as a way for me to learn more about Google's AppEngine. It didn't take very long to get it up and running, and it seemed to work fairly well. AppEngine and Extensions I was able to basically leave the site alone on AppEngine for several months--through about September 2009. In that time, I came up with a Firefox extension to make its use more convenient. The extension allows you to quickly get a shortened URL for the page you're currently looking at, and a couple of context menu items let you get a short URL for things like specific images on a page. Also included in the extension is a preview for 2ze.us links. The preview can tell you the title and domain of the link's target. It can tell you how much smaller the 2ze.us URL is compared to the full URL. Finally, it displays how many times that particular 2ze.us link has been clicked. … -
On Security and Python's Exec
A recent project at work has renewed my aversion to Python's exec statement--particularly when you want to use it with arbitrary, untrusted code. The project requirements necessitated the use of exec, so I got to do some interesting experiments with it. I've got a few friends who, until I slapped some sense into them, were seemingly big fans of exec (in Django projects, even...). This article is for them and others in the same boat. Take this example: #!/usr/bin/env python import sys dirname = '/usr/lib/python2.6/site-packages' print dirname, 'in path?', (dirname in sys.path) exec """import sys dirname = '/usr/lib/python2.6/site-packages' print 'In exec path?', (dirname in sys.path) sys.path.remove(dirname) print 'In exec path?', (dirname in sys.path)""" print dirname, 'in path?', (dirname in sys.path) Take a second and examine what the script is doing. Done? Great... So, the script first makes sure that a very critical directory is in my PYTHONPATH: /usr/lib/python2.6/site-packages. This is the directory where all of the awesome Python packages, like PIL, lxml, and dozens of others, reside. This is where Python will look for such packages when I try to import and use them in my programs. Next, a little Python snippet is executed using exec. Let's say this snippet … -
Pip pip hurra!
Què voleu, estic content de veure que una eina com pip funciona tan bé. Pip és una eina per a la instal·lació de paquets i dependències per Python, molt més avançada que easy_install ja que permet tot el que feia easy_install però a més, permet mantenir d'una manera fàcil un arxius amb totes les dependències del nostre projecte. Ens permet instal·lar paquests de Python des dels repositoris de Pypi, des de subversion, git, mercurial a través d'un fitxer de requeriments simple i a la vegada funcional. Mode batalleta on: Ahir vespre estava fent feina amb un projecte mascota que tinc, un motor de reserves per hotels i cadenes hoteleres fet amb Python i Django. El projecte necessita de força llibreries: la darrera versió de django, nose pels tests, sphinx per la documentació, django debug toolbar, django extensions, south per la migració de dades, ipython, ipdb, pep8, coverage, pytlint. Tot això (i algunes més que s'hi afegiran) constitueixen l'entorn de desnvolupament del projecte. Actualment faig feina amb tres ordinadors: el fix (el PPC del que tant he parlat per aquí), portàtil un Dell D820 i un Dell de 10". Segons on estic i el que he de fer en faig servir … -
Updates for django-lastfm and django-sphinxdoc
After reading The Hitchhiker’s Guide to Packaging I update my packages for django-lastfm and django-sphinxdoc. There are no functionional improvements, so you don’t need to update them. -
Updates for django-lastfm and django-sphinxdoc
After reading The Hitchhiker’s Guide to Packaging I update my packages for django-lastfm and django-sphinxdoc. There are no functionional improvements, so you don’t need to update them. -
Announcing django-moderation
django-moderation is reusable application for Django framework, that allows to moderate any model objects. Code can be found at http://github.com/dominno/django-moderation Possible use cases: User creates his profile, profile is not visible on site. It will be visible on site when moderator approves it. User changes his profile, old profile data is visible on site. New data will be visible on site when moderator approves it. Features: configurable admin integration(data changed in admin can be visible on site when moderator approves it) moderation queue in admin html differences of changes between versions of objects configurable email notifications custom model form that allows to edit changed data of object 100% PEP8 correct code test coverage > 80% Requirements python >= 2.4 django >= 1.1 Installation Download source code from http://github.com/dominno/django-moderation and run installation script: $> python setup.py install Configuration Add to your INSTALLED_APPS in your settings.py: moderation Run command manage.py syncdb Register Models with moderation from django.db import models from moderation import moderation class YourModel(models.Model): pass moderation.register(YourModel) Register admin class with your Model from django.contrib import admin from moderation.admin import ModerationAdmin class YourModelAdmin(ModerationAdmin): """Admin settings go here.""" admin.site.register(YourModel, YourModelAdmin) If you want to disable integration of moderation in admin, add admin_intergration_enabled = … -
Cache Machine: Automatic caching for your Django models
Cache Machine: Automatic caching for your Django models. This is the third new ORM caching layer for Django I’ve seen in the past month! Cache Machine was developed for zamboni, the port of addons.mozilla.org to Django. Caching is enabled using a model mixin class (to hook up some post_delete hooks) and a custom caching manager. Invalidation works by maintaining a “flush list” of dependent cache entries for each object—this is currently stored in memcached and hence has potential race conditions, but a comment in the source code suggests that this could be solved by moving to redis. -
Django User Profiles - Simple yet powerful
So you're building a web application, and using the excellent contrib.auth subsystem to manage user accounts. Most probably you need to store additional information about your users, but how? Django profiles to the rescue! Django provides a lightweight way of defining a profile object linked to a given user. The profile object can differ from project to project, and it can even handle different profiles for different sites served from the same database. In a nutshell, using Django profiles consists of 3 steps: Define a model that holds the profile information. Tell Django where to look for the profile object. Create the user profile as needed. Defining the user profile model The only requirement Django places on this model is that it have a unique ForeignKey to the User model, and is called user. Other than that, you can define any other fields you like. For our example, we'll create 2 user profile fields (url and company). account/models.py from django.db import models from django.contrib.auth.models import User class UserProfile(models.Model): user = models.ForeignKey(User, unique=True) url = models.URLField("Website", blank=True) company = models.CharField(max_length=50, blank=True) Tell Django about the profile object Accessing a users profile is done by calling user.get_profile(), but in order … -
Django User Profiles - Simple yet powerful
So you're building a web application, and using the excellent contrib.auth subsystem to manage user accounts. Most probably you need to store additional information about your users, but how? Django profiles to the rescue! Django provides a lightweight way of defining a profile object linked to a given user. The profile object can differ from project to project, and it can even handle different profiles for different sites served from the same database. In a nutshell, using Django profiles consists of 3 steps: Define a model that holds the profile information. Tell Django where to look for the profile object. Create the user profile as needed. Defining the user profile model The only requirement Django places on this model is that it have a unique ForeignKey to the User model, and is called user. Other than that, you can define any other fields you like. For our example, we'll create 2 user profile fields (url and company). account/models.py from django.db import models from django.contrib.auth.models import User class UserProfile(models.Model): user = models.ForeignKey(User, unique=True) url = models.URLField("Website", blank=True) company = models.CharField(max_length=50, blank=True) Tell Django about the profile object Accessing a users profile is done by calling user.get_profile(), but in order … -
Django User Profiles - Simple yet powerful
So you're building a web application, and using the excellent contrib.auth subsystem to manage user accounts. Most probably you need to store additional information about your users, but how? Django profiles to the rescue! Django provides a lightweight way of defining a profile object linked to a given user. The profile object can differ from project to project, and it can even handle different profiles for different sites served from the same database. In a nutshell, using Django profiles consists of 3 steps: Define a model that holds the profile information. Tell Django where to look for the profile object. Create the user profile as needed. Defining the user profile model The only requirement Django places on this model is that it have a unique ForeignKey to the User model, and is called user. Other than that, you can define any other fields you like. For our example, we'll create 2 user profile fields (url and company). account/models.py from django.db import models from django.contrib.auth.models import User class UserProfile(models.Model): user = models.ForeignKey(User, unique=True) url = models.URLField("Website", blank=True) company = models.CharField(max_length=50, blank=True) Tell Django about the profile object Accessing a users profile is done by calling user.get_profile(), but in order … -
Refugee Buddy: a project of OzSiCamp Sydney 2010
Last weekend, I attended Social Innovation Camp Sydney 2010. SiCamp is an event where several teams have one weekend in which to take an idea for an online social innovation technology, and to make something of it. Ideally, the technology gets built and deployed by the end of the camp, but if a team doesn't reach that stage, simply developing the concept is an acceptable outcome as well. I was part of a team of seven (including our team leader), and we were the team that built Refugee Buddy. As the site's slogan says: "Refugee Buddy is a way for you to welcome people to your community from other cultures and countries." It allows regular Australians to sign up and become volunteers to help out people in our community who are refugees from overseas. It then allows refugee welfare organisations (both governmnent and independent) to search the database of volunteers, and to match "buddies" with people in need. Of the eight teams present at this OzSiCamp, we won! Big congratulations to everyone on the team: Oz, Alex, James, Daniela, Tom, (and Jeremy — that's me!) and most of all Joy, who came to the camp with a great concept, and … -
Easy create or update
One common database operation that isn't supported out of the box by Django's ORM is create_or_update - in other words, given a set of parameters, either update an existing object or create a new one if there isn't one already. The naive implementation is to do a get() on the model, catching the DoesNotExist exception if there's no match and instantiating a new object, then updating the attributes and saving. (You wouldn't want to use get_or_create here, as that doesn't allow you to update the instance if it already exists, so you'd have some duplication of code and db queries). try: obj = MyModel.objects.get(field1=value1) except MyModel.DoesNotExist: obj = MyModel() obj.field1 = field1 obj.field2 = value2 obj.save() The only problem with this is that it creates multiple queries: one to get the existing row, and then two to save it - Django checks to see if it should do an insert or an update when you save, which costs another query. Most of the time, this doesn't massively matter: creating and updating is usually done outside of the standard page rendering flow, so it's not a huge problem if it's a tiny bit slower. But there are times when you do … -
Einladung zur Django-UserGroup Hamburg am 23. März
Das nächste Treffen der Django-UserGroup Hamburg findet am Dienstag, den 23.03.2010 um 19:30 statt. Wie bei den letzten Malen treffen wir uns wieder in den Räumen der CoreMedia AG in der Ludwig-Erhard-Straße 18 in 20459 Hamburg (Anfahrtsbeschreibung auf Google Maps). Bitte am Eingang bei CoreMedia AG klingeln, in den 3. Stock fahren und oben am Empfang nach der Django-UserGroup fragen. Da wir in den Räumlichkeiten einen Beamer zur Verfügung haben hat jeder Teilnehmer die Möglichkeit einen kurzen Vortrag (Format: Lightning Talks oder etwas länger) zu halten. Die meisten Vorträge ergeben sich erfahrungsgemäß vor Ort. Eingeladen ist wie immer jeder der Interesse hat sich mit anderen Djangonauten auszutauschen. Eine Anmeldung ist nicht erforderlich. Weitere Informationen über die UserGroup gibt es in unserem Git Repository unter www.dughh.de und im Wiki des Deutschen Django-Vereins. -
Easy create or update
One common database operation that isn't supported out of the box by Django's ORM is create_or_update - in other words, given a set of parameters, either update an existing object or create a new one if there isn't one already. The naive implementation is to do a get() on the model, catching the DoesNotExist exception if there's no match and instantiating a new object, then updating the attributes and saving. (You wouldn't want to use get_or_create here, as that doesn't allow you to update the instance if it already exists, so you'd have some duplication of code and db queries). try: obj = MyModel.objects.get(field1=value1) except MyModel.DoesNotExist: obj = MyModel() obj.field1 = field1 obj.field2 = value2 obj.save() The only problem with this is that it creates multiple queries: one to get the existing row, and then two to save it - Django checks to see if it should do an insert or an update when you save, which costs another query. Most of the time, this doesn't massively matter: creating and updating is usually done outside of the standard page rendering flow, so it's not a huge problem if it's a tiny bit slower. But there are times when you do … -
Easy create or update
One common database operation that isn't supported out of the box by Django's ORM is create_or_update - in other words, given a set of parameters, either update an existing object or create a new one if there isn't one already. The naive implementation is to do a get() on the model, catching the DoesNotExist exception if there's no match and instantiating a new object, then updating the attributes and saving. (You wouldn't want to use get_or_create here, as that doesn't allow you to update the instance if it already exists, so you'd have some duplication of code and db queries). try: obj = MyModel.objects.get(field1=value1) except MyModel.DoesNotExist: obj = MyModel() obj.field1 = field1 obj.field2 = value2 obj.save() The only problem with this is that it creates multiple queries: one to get the existing row, and then two to save it - Django checks to see if it should do an insert or an update when you save, which costs another query. Most of the time, this doesn't massively matter: creating and updating is usually done outside of the standard page rendering flow, so it's not a huge problem if it's a tiny bit slower. But there are times when you do … -
Announcing twod.wsgi: Better WSGI support for Django
We are very pleased to announce the first alpha release of twod.wsgi, a library to make WSGI a first-class citizen in Django applications.twod.wsgi allows Django developers to take advantage of the huge array of existing WSGI software, to integrate 3rd party components which suit your needs or just to improve things which are not within the scope of a Web application framework.It ships with a PasteDeploy application factory (which gives the enterprise some of what it needs) and full-featured request objects extended by WebOb. It also gives you the ability to serve WSGI applications inside Django, so you can filter the requests they get and/or the responses they return (e.g., to implement Single Sign-On mechanisms). And there's more!For example, if you wanted to integrate your authentication mechanisms with your Trac application, you could do it in 11 lines of code:from django.shortcuts import redirectfrom django.conf import settingsfrom twod.wsgi import call_wsgi_appfrom trac.web.main import dispatch_request as trac_appdef make_trac(request, path_info): if path_info.startswith("/login"): return redirect(request.script_name + "/login") elif path_info.startswith("/logout"): return redirect(request.script_name + "/logout") request.environ['trac.env_path'] = settings.TRAC_PATH return call_wsgi_app(trac_app, request, path_info)Don't be fooled by the "first alpha release": It's rock-solid. We've been using it for months in our Web site and it's never ever failed. It … -
Debugging production Django deployment
Deploying Django is a process that can drive one bananas. There are a lot of things to setup to go from your development environment to the production. Aside from the regular hassles - there come special little buggers that can really make you mad. If you ever had problems with 500.html pages, url configurations or import errors - you know what I mean. However it doesn't all have to be that bad. There are quite a few steps you can take early on to minimize the pain. If you do get into trouble - there are some things you can do to debug out of it. Preventative Measures Deploy early If you want to avoid the hassle of debugging 100 things at once, deploy your project as soon as possible. By "as soon as possible" I mean right after you create it - when there are no models, views and funky url settings! Commit often You are of course using source control for your project, correct? By committing often you allow for greater granularity of your project. In a way you "isolate" bugs in a particular commit. This makes finding them later on particularly easy. Deploy often Same as #1 - … -
Announcing django-cachebot
Announcing django-cachebot. The ORM caching space around Django is heating up. django-cachebot is used in production at mingle.com and takes a more low level approach to cache invalidation than Johnny Cache, enabling you to specifically mark the querysets you wish to cache and providing some advanced options for cache invalidation. Unfortunately it currently relies on a patch to Django core to enable its own manager. -
libjpeg symbol not found error with PIL on 10.6 Snow Leopard
If you get the following error, while Installing PIL on Mac OS X 10.6 Snow Leopard read on for a possible solution: >>> from PIL import _imaging Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: dlopen(/Library/Python/2.6/site-packages/PIL/_imaging.so, 2): \ Symbol not found: _jpeg_resync_to_restart Referenced from: /Library/Python/2.6/site-packages/PIL/_imaging.so Expected in: flat namespace in /Library/Python/2.6/site-packages/PIL/_imaging.so Popular how-tos on the web indicated that it is neccessary to force Python on Snow Leopard in 32bit mode to be able to install the Psycopg2 adapter for PostgreSQL. So you might have used the following command on your system: defaults write com.apple.versioner.python Prefer-32-Bit -bool yes Now you get the traceback shown above while installing or using PIL. This might result from an _imaging.so module (for PIL) build with a 64bit version of libjpeg, which now fails to load in a 32bit python interpreter. We were able to solve the problem by installing a universal libjpeg package, found here: http://ethan.tira-thompson.org/Mac_OS_X_Ports.html and recompiling PIL to use this libjpeg version. Now PIL works in 32bit and 64bit mode. -
Pycon 2010 report III: Sprints
My report for the sprints of Pycon 2010. This isn't a general review of the sprints, just how it affected me.Pinax SprintI don't have a hard count of how many people participated on Pinax this year. Last year's sprint looked like we had a lot more, but last year the Pinax room was home to people doing other things, albeit mostly Django related stuff. In any case, this year we had probably about 10 people working on Pinax, or things that went directly into Pinax.While James Tauber is the leader of the Pinax community, this year Brian Rosner stepped up and did an amazing job being both a technical resource and director of geeks. The mutual clarity of vision and obvious telepathy between Brian and James is truly a joy to behold. I also appreciate the entire Pinax community. Besides coaching me on Git branches (work uses SVN so I just don't get enough Git practice) they also gracefully understood that I was a bit distracted this year. My specific contributions to PinaxOne of the things that had bugged me about Pinax for some time were the individual project tag apps. These were a per project extension of django-tagging, and …