HARI MAHADEVAN (何瑞理)

A few points on integrating Sphinx with a Django redistributable project for generating documentation embedded in the source files. Project directory structure should look like this: django-redistributable/ demo/ demo/ settings.py urls.py wsgi.py templates/ manage.py docs/ conf.py index.rst Makefile make.bat redistributable/ models.py views.py templates/ static/ tests/ setup.py MANIFEST.in README.rst LICENSE requirements.txt Install sphinx and sphinx-autobuild using pip. Run sphinx-quickstart from the docs folder. Provide default answers for all prompts. Edit docs/conf.py such that the redistributable package and the demo project's apps are importable from the docs folder. At the top of the conf.py file: import os import sys import django sys.path.insert(0, os.path.dirname(os.path.dirname(__file__))) sys.path.append(os.path.join(os.path.dirname(os.path.dirname(__file__)), 'demo')) Set...

One useful Django template tag is to retrieve the template filename from inside the template. Unfortunately, Django built in tags do not provide one for this. However, you can write a simple tag to accomplish this. Here's are two tags, that return either the base filename or the full filename. from django import template register = template.Library() @register.simple_tag(takes_context=True) def basefilename(context): '''Returns filename minus the extension''' return context.template_name.split('.')[0] @register.simple_tag(takes_context=True) def fullfilename(context): '''Returns full filename with the extension''' return context.template_name To be complete, tthere should be another tag that returns the filename with its entire path. But I haven't figured out how to do this -- at least from within the confines of the template tag framework. 

My first production level shell script is out. Yes, after two decades spent in the depths of code, I have finally published a shell script that is worthy of being called 'code'. It's something that started as a few lines hack to update a Linux box with a series of packages that needed to be installed to deploy a Django web app that eventually grew to 300+ lines of madness (I can't find anything else to describe shell scripting language) that I have used to create consistent configuration across a few servers. Without much ado, here it is: https://github.com/harikvpy/deploy-django.git .

My first production level shell script is out. Yes, after two decades spent in the depths of code, I have finally published a shell script that is worthy of being called 'code'. It's something that started as a few lines hack to update a Linux box with a series of packages that needed to be installed to deploy a Django web app that eventually grew to 300+ lines of madness (I can't find anything else to describe shell scripting language) that I have since used to create consistent configuration across a few servers and apps. Without much ado, here it is: https://github.com/harikvpy/deploy-django.git .

First step is to install PostgreSQL on Ubuntu. In its default installation, Ubuntu does not included PostgreSQL. So uou have to install it separately. sudo apt-get install postgresql Now install the python module for accessing PostgreSQL -- psycopg2. You have two choices here -- either install this from the OS package manager or manually using pip. Which approach to choose depends on your python development environment. i. If you're using the system python as development environment, you may install psycopg2 from the OS package manager. You can do this by $ sudo apt-get install python-psycopg2 ii. However, if your python development environment is based on a virtual environment, the above approach will not work. This is because the above installs psycopg2 on the system python dist-packages, which does not copied into the virtual environment when it's created. This is the behavior even if the package is installed before the virtual environment is created. So in this ca...

Django has excellent support for building a multi language multi culture application. However, there are a few interesting bits about its implementation of the internationalization feature that can prove to be minor annoyances in truly localizing yoru web based application. This post aims to discusses these issues and highlights the solutions for them. It matters where you run 'makemessages' command from The core command that prepares the application for localization,  makemessages  can be launched from two locations and depending on where it's launched it behaves slightly differently. The command can be launched from project root folder or from an application folder. If started from the project root, it attempts to extract all the localizable strings from all installed apps and put them in the  *.po  file. However, if started from an application subfolder, it only extracts the strings from that application's files. The key issue here is that  mak...

This is more for my own reference as I often forget the various steps that I followed to get an environment set up. This post lists the steps that I followed to setup an Ubuntu Server for Python/Django/MySQL environment. The steps are drawn from various resources on the web -- official documentation from Ubuntu, some blog posts and a few pointers on stackexchange/stackoverflow. All credits due to all the kind souls who shared knowledge.

Here's a cool bit of code snippet that I found from the web (original post here ). I'm recording it here for my own easy reference without having to google it all the time. It describes a simple technique to debug Django templates using the python debugger - pdb. @register.filter def pdb(element): import pdb; pdb.set_trace() return element Now, inside a template you can do {{ template_var|pdb }} and enter a pdb session (given you're running the local development server) where you can inspect element to your heart's content. It's a very nice way to see what's happened to your object when it arrives at the template.