The other day at work, I found myself needing to see a list of Subversion commits by a specific user. I spent a few minutes looking at the svn log help, but nothing seemed to be designed to show commits by user. It took me a while to find something to do the trick, but this is it:
svn log | sed -n '/username/,/-----$/ p'
Gotta love sed!
One of the tools I find myself using more and more each day is the amazing grep. It helps me narrow down the list of potential problem children in my code. Sometimes it can even tell me exactly where I need to look if my parameters are specific enough.
For example, the other day, I had a problem where some Python code was attempting to call isdigit() on an integer, when the variable was supposed to be a string. I could have scoured the code manually for all occurrences of the word "isdigit", or I could have used a "search in files" sort of feature in any useful text editor. There are likely other options too. However, I opted to use grep to find what I was looking for.
In the process of fixing this bug, I learned that grep offers the option of displaying a few lines of context around your matching text. There are a few ways you can tell grep to give you some context:
-A NUM, --after-context=NUM
Print NUM lines of trailing context after matching lines. Places a line containing -- between contiguous groups of matches.
-B NUM, --before-context=NUM
Print NUM lines of leading context before matching lines. Places a line containing -- between contiguous groups of matches.
-C NUM, --context=NUM
Print NUM lines of output context. Places a line containing -- between contiguous groups of matches.
I thought this was so useful that I wrote a small shell script to wrap up my common options for grepping--recursive search, display line numbers, and (now) showing some context. Eventually I got around to cleaning up the output by dirtying up the script. Cleaning up the output involved only displaying a matching filename one time, with the line numbers for the context and matching lines below it. I also thought it would be easier to find matching lines if I could colorize the matched text. Here's my script as of noon today.
#!/bin/bash # Recursively greps for some text in files in the current directory with some # context lines. GREEN=`echo -e '\033[41;30;1m'` NORMAL=`echo -e '\033[0m'` FIND=$1 grep --exclude=*.svn* --exclude=*.swp -rnC 5 "$FIND" * | \ awk '{split($1, a, "-"); split(a[1], b, ":"); \ if (b[1] != file) { file=b[1]; print file; } \ sub(file, "", $0); print $0; }' | \ sed -e "s/$FIND/$GREEN&$NORMAL/g;s/^[-\:]//g"
I'm sure there are ways to make this more elegant, but I'm sure happy with it. This little dandy assisted me just this morning in helping a friend resolve some Django bugs!
Here's a screenshot:
Today I found myself trying to figure out how to make a terminal window stay permanent on my desktop or dashboard on OSX, similar to what I've done in the past with Linux. I just wanted to have the terminal window monitoring things in the background for me. Actually, all I wanted to do was keep track of when my local working copy of our Subversion repository was out of sync. I wanted a solution that would keep out of my way, but I also wanted it to be easy.
My search for a solution seemed short-lived when a Google search suggested a dashboard widget for the Terminal application. The problem with it was that the download server was dead or simply blocked by my company's Internet filter. One way or another, it wasn't long before I went in search of another solution.
At that very instant, I received a Growl notification from some program. That's when it dawned on me--I could tell Growl to tell me when my working copy was out of sync. I had done stuff like that in the past, so I set out to write my solution. This is what I came up with:
#!/bin/bash MY_BOX=[my IP address] DEV_ROOT='/path/to/svn/working copy' cd $DEV_ROOT MY_REV=`svn log --limit 1 | awk '/^r/ {print $1}' | sed 's/[^0-9]//g'` SVN_REV=`svn log --limit 1 -r HEAD | awk '/^r/ {print $1}' | sed 's/[^0-9]//g'` if [[ $MY_REV != $SVN_REV ]]; then ssh username@$MY_BOX "growlnotify -s -d47111 -n 'iTerm' -t 'Out Of Sync' -m 'Your working copy is out of sync. Repository is at revision $SVN_REV, and your working copy is at $MY_REV.'" fi
Now, a little bit about my environment. As I've mentioned before, all of our development really takes place on Linux-powered virtual machines. We simply use our Macs as the system to interact with those virtual machines. That is why there's the ssh line in that script.
Basically, this script just checks the most recent revision in your local working copy. Then it checks the latest revision in the repository itself. It compares the two revision numbers, and if it finds a difference, it will SSH into my OSX box to send me a Growl notification. On the OSX side, I have Growl and growlnotify installed. Here's a summary of the options to growlnotify:
This is a fabulous little reminder to me. I have it set up as a cronjob that runs every minute on my Linux-powered development virtual machine. Hopefully this will help others!
Some of you may well know that I was previously an subversion user, more out of comfort than necessity. SVN was the first version control system that I became well acquainted with, so it just seemed like a natural choice for me when I thought I needed version control.
Several months ago I read a blog article by a buddy, in which he briefly discussed Mercurial. I had been meaning to give some distributed version control systems a shot after some disasters related to the centralized nature of SVN. This blog article prompted me to take a stab at Mercurial and some others.
Within a few days I was sold on Mercurial. I won't go into details simply because I'm not one for religious wars that way. Let's just say that Mercurial seemed to be perfect for my wants and needs.
There were, however, a few things about using Mercurial that I miss from the SVN world. One such thing is that you can update several "working copies" of something in SVN with a single command. For example, I keep a lot of my 3rd party Django applications in one directory. Many of these applications use SVN. Sometimes I'll just run a command like this:
svn up /path/to/third/party/apps/*
Each project that uses SVN will automatically be updated without much fuss with such a command. However, with Mercurial, it appears that you need to be in an actual Mercurial repository in order to update it. There are extensions to get around this problem, but I was looking for something a little different.
Since I use Linux almost exclusively, I didn't feel bad about just using the power within to do the work. The following command does everything I need it to:
find -name ".hg" -type d | xargs -t -i bash -c "(cd {}; hg pull; hg up)"
This command finds any directories called .hg anywhere under your current location on the filesystem. Any matches will be used in the command at the end: cd {}; hg pull; hg up
So far I haven't had any problems with this command, but your mileage may vary. To make things even easier, I made an alias for this rather long command:
alias hgupall='find -name ".hg" -type d | xargs -t -i bash -c "(cd {}; hg pull; hg up)"'
I put that line in my ~/.bashrc script, which is executed each time I log into my computer. With that in place, all I need to do is something like this:
cd /path/to/third/party/apps hgupall
And the aliased command handles the rest. Pretty slick stuff. Hooray for Mercurial and Linux!
Last night I noticed that Google Code is actually offering the Mercurial project hosting that they promised back in April. I guess it's been around for most of May, but I never saw any news to suggest that it was actually public. As soon as I noticed it, I converted one of my less-known, less-used SVN projects to Mercurial. I'm really liking it.
I need to do a bit more work on this particular project before I announce it to the world, but it's out there, and it's Mercurial powered now babay. I think I will be leaving most of my other projects in SVN so I don't upset all of the other people who actually use them.
Oh, I also noticed that the project quotas were bumped up quite a bit. Now each project seems to get a whopping 1GB of space for free!!! What do you have to say about that, BitBucket/GitHub/Assembla/[insert dirty, rotten free open source project hosting host name here]?!
Hooray for Google Code!
It's been a while since I wrote a blog article, so I'm using this one-liner as an excuse. In case you're new here, I do a lot of Python development. In the world of Python, you need to have a special file in a directory before you can use Python code within that directory. Yeah, yeah... that's not exactly the clearest way to explain things, but it'll have to do.
This special file is called __init__.py. Having this file in a directory that contains Python code turns that directory into what's called a "python package." We like Python packages. They make our lives so much fun!
Anyhoo, I was working on a project last night, and I wanted to create a bunch of placeholder directories that I plan to use later on. I plan on keeping Python code in these directories, so putting the special __init__.py file in them is what I was looking to do. I didn't want to have to create the __init__.py file in each directory manually, or copy/paste the file all over the place, so I investigated a way to do it quickly from the command line.
One of my buddies brought an interesting command to my attention recently: xargs. I had seen it before in various tutorials online, but I never bothered to learn about it. This seemed like as good a time as any, so I started playing. The result of my efforts follows:
find . -type d | xargs -I {} touch {}/__init__.py
What it does is:
Turns out that xargs can be used for all sorts of good stuff. My friend brought it up as a way to get rid of those nasty .svn directories on his path to "Mercurial bliss."
find . -name ".svn" -type d | xargs -I {} rm -Rf {}
How beautiful!
Yesterday I had one of my coworkers ask me what I thought to be a simple Django question: "in the admin pages im trying to show fields from different tables but it wont let me." I clarified the problem with this chap, and eventually suggested using something like this:
from django.contrib import admin from project.app.models import AwesomeModel class AwesomeModelAdmin(admin.ModelAdmin): list_display = ('fk_field__fk_attr1', 'fk_field2__fk_attr') admin.site.register(AwesomeModel, AwesomeModelAdmin)
As it just so happens, that does not work with Django as of SVN revision 9907 (or any previous versions I presume). You cannot span relationships in your Django models from the list_display item in your model admin classes. This completely caught me off guard, so I looked through the docs a bit. I found some work-arounds for the issue, but they all seemed pretty ridiculous and, more importantly, violations of the DRY principle. It also surprised me that I hadn't noticed this problem before! I guess that's why it's not fixed yet--it's not really required by all that many people?
Anyway, I did a bit of research into the issue. I stumbled upon a ticket which appears to be aimed at resolving this problem. The ticket is pretty old, and it looks like it's still up in the air as to whether or not the patches will be applied to trunk. That wasn't very encouraging.
Being the nerd that I am, I set out to find an "efficient" solution of my own for the problem, without meddling with the Django codebase itself. Below you will find my attempt at some pure Python hackery (no Django involved other than overriding a method) to make our lives easier until someone with some pull in the Django community gets something better into Django's trunk.
Disclaimer: this might well be the absolute worst way to approach the problem. I'm okay with that, because I still like the results and I learned a lot while producing them. I don't have any benchmarks or anything like that, but I wouldn't complain if someone else came up with some and shared them in the comments.
from django.contrib import admin def mygetattr(obj, hier): """ Recursively attempts to find attributes across Django relationships. """ if len(hier): return mygetattr(getattr(obj, hier[0]), hier[1:]) return obj def dynamic_attributes(self, attr, *args, **kwargs): """ Retrieves object attributes. If an attribute contains '__' in the name, and the attribute doesn't exist, this method will attempt to span Django model relationships to find the desired attribute. """ try: # try to get the attribute the normal way return super(admin.ModelAdmin, self).__getattribute__(attr, *args, **kwargs) except AttributeError: # the attribute doesn't exist for the object. See if the attribute has # two underscores in it (but doesn't begin with them). if attr and not attr.startswith('__') and '__' in attr: # it does! make a callable for the attribute new_attr = lambda o: mygetattr(o, attr.split('__')) # add the new callable to the object's attributes setattr(self, attr, new_attr) # return the callable return new_attr # override the __getattribute__ method on the admin.ModelAdmin class admin.ModelAdmin.__getattribute__ = dynamic_attributes
This code could be placed, for example, in your project's root urls.py file. That would make it so that all of the apps in your project could benefit from the relationship spanning. Alternatively, you could place it in the admin.py module for a specific application. It would just need to be someplace that was actually processed when your site is "booted up."
Basically this code will override the built-in __getattribute__ method for the django.contrib.admin.ModelAdmin class. When an attribute such as fk_field__fk_attr1 is requested for an object, the code will check to see if an attribute already exists with that name. If so, the existing attribute will be used. If not, it chops up the attribute based on the __ (double underscores) that it can find. Next, the code does some recursive getattr() calls until it runs out of relationships to hop across so it can find the attribute you really want.
Once all of that is done, the end result is placed in a callable attribute for the respective admin.ModelAdmin subclass so it won't have to be built again in the future. The new callable attribute is what is returned by the __getattribute__ function.
Now, there are some funky things that you must be aware of before you go an implement this code on your site. Very important things, I might add. Really, I've only found one large caveat, but I wouldn't be surprised if there are others. The biggest issue is that you have to define the list_display attribute of your ModelAdmin class after you register the model and the admin class with the admin site (see below for an example). Why? Because when the Django admin validates the model's admin class, it checks the items in the list_display. If it can't find a callable attribute called fk_field__fk_attr1 during validation, it will complain and the model won't be registered in the Django admin site. The dynamic attributes that are built by my hackery are added to the object after it is validated (more accurately, when the list page is rendered, from what I have observed).
This is by far the most disgusting side effect of my hackery (at least that I have observed so far). I don't like it, but I do like it a lot more than defining loads of callables in several ModelAdmin classes just to have something simple show up in the admin's list pages. You're free to form your own opinions.
Using the original code I offered to my coworker, this is how it would have to look in order for my hack to work properly.
from django.contrib import admin from project.app.models import AwesomeModel class AwesomeModelAdmin(admin.ModelAdmin): pass admin.site.register(AwesomeModel, AwesomeModelAdmin) AwesomeModelAdmin.list_display = ('fk_field__fk_attr1', 'fk_field2__fk_attr')
See, I told you it was funky. But again, I'll take it.
If any of you have thoughts for how this could be improved, please share. Constructive criticism is very welcome and encouraged. Please also consider reviewing the ticket that is to address this problem.
With all of the hype that git has been receiving lately, I started playing with it a while back to see if it suited me and my wants/needs. I found it to be an interesting utility. I won't go into any details simply because I'm not really all that knowledgeable about all the ins and outs of version control systems, but I will say that I have decided I like it. I'm still not sure whether I prefer GIT over SVN or SVN over GIT.
My problem is that basically all of my projects are based on SVN repositories. I don't want to have to start up a new GIT repository for each of my past projects. Fortunately, there is an interface for GIT to use SVN repositories called git-svn. I use this utility primarily on my EeePC because it saves a good amount of space on my small disk (the git-svn versions of the working copies are typically about half the size of their svn counterparts). Sometimes it's a little wacky, but it works well enough for my needs.
I started using this git-svn utility on a Debian-based distribution. That meant it was insanely simple to get up and running: sudo apt-get install git-svn. I recently installed Slackware 12.2, and I was surprised to find out that the git-svn utility wasn't immediately available to me.
I did some googling to see if others had encountered the same problem. There were several accurate hits, but I couldn't quite find the solution I needed. In the end, I finally got things working. The following information describes what I did to achieve this monumental success.
The first roadblock that I encountered, obviously, was finding out that git-svn didn't work on my shiny new Slackware installation. After doing a bit of research, I learned that I could substitute the familiar git-svn command with git svn and continue using it as I previously had.
Once I learned about git svn and tried it out, I got a nasty error about Alien/SVN. I've lost track of the original error, and for that I apologize. Doing a little bit of research led me to execute this command as root:
cpan Alien::SVN
I'm not sure exactly whether that step is required, but you might as well do it :).
Next, I downloaded a couple SlackBuilds to create my own Slackware packages suited for my computer.
For each SlackBuild, you must download the original source code along with the actual SlackBuild itself. For example, when retrieving the necessary files for swig, I must download both swig-1.3.35.tar.gz and swig.tar.gz from the link specified. Here are some example commands, which should be run as root:
mkdir -p ~/downloads/slackbuilds; cd ~/downloads/slackbuilds wget http://slackbuilds.org/slackbuilds/12.2/development/swig.tar.gz tar zxf swig.tar.gz cd swig/ wget http://downloads.sourceforge.net/swig/swig-1.3.35.tar.gz ./swig.SlackBuild installpkg /tmp/swig-1.3.35-i486-1_SBo.tgz
The commands above should create a new directory in /root/ called downloads/slackbuilds. Next, the SlackBuild for swig will be downloaded and extracted, after which the swig source code will be downloaded. The SlackBuild is executed, rendering an installable Slackware package. Finally, the package is installed onto the system.
The process is basically the same for the subversion-bindings SlackBuild. On my system, however, I had to modify the stock SlackBuild slightly. I didn't install Apache on my EeePC because I don't use it and it would just be taking up space. When I tried to execute the SlackBuild for subversion-bindings straight from the archive, it complained about a missing apxs file, which has something to do with Apache.
To avoid the error, I modified the subversion-bindings.SlackBuild script to ignore the apxs thingy. The original ./configure section looked like this:
CFLAGS="$SLKCFLAGS" \ ./configure \ --prefix=/usr \ --mandir=/usr/man \ --enable-shared \ --disable-static \ --with-apr=/usr \ --with-apr-util=/usr \ --with-apxs=/usr/sbin/apxs \ --with-neon=/usr \ --with-zlib=/usr \ --with-pic \ --with-ssl \ --build=$ARCH-slackware-linux
I just removed the line that says --with-apxs=/usr/sbin/apxs \ and ran the SlackBuild script again. Worked like a charm.
At this point everything appeared to be able to work properly. Running git svn from the command line no longer spit out that nasty error I mentioned earlier. Instead it gave me the options I would expect to see.
That's when I tried to update an existing working copy of an SVN repository. It gave me this error:
$ git svn rebase Authentication realm: <http://special.domain.com:80> Subversion - code Password for 'myuser': Can't locate Term/ReadKey.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.10.0/i486-linux-thread-multi /usr/lib/perl5 /site_perl/5.10.0 /usr/lib/perl5/5.10.0/i486-linux-thread-multi /usr/lib /perl5/5.10.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.10.0 /i486-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5 /vendor_perl .) at /usr/libexec/git-core/git-svn line 3071.
That's not very nice, now is it? The solution was fairly simple: install Perl's Term::ReadKey module. As root, execute the following command:
cpan Term::ReadKey
After doing that I was able to happily update my working copy and move on.
I don't envision that this article will be the all-knowing, all-powerful resource for how to use git-svn on Slackware, but I sure hope it will help some other folks who run into the same problems as me.
This article is a related to my previously posted article about installing Django, an advanced Web framework for perfectionists, on your own computer. Now we will learn how to install Django on a shared hosting account, using Site5 and fastcgi as an example. Depending on your host, you may or may not have to request additional privileges from the support team in order to execute some of these commands.
Note: Django requires at least Python 2.3. Newer versions of Python are preferred.
Note: This HOWTO assumes familiarity with the UNIX/Linux command line.
Note: If the wget command doesn't work for you (as in you don't have permission to run it), you might try curl [url] -O instead. That's a -O as in upper-case o.
Site5 (and many other shared hosting providers that offer SSH access) already has Python installed, but you will want to have your own copy so you can install various tools without affecting other users. So go ahead and download virtual python:
mkdir ~/downloads cd ~/downloads wget http://peak.telecommunity.com/dist/virtual-python.py
Virtual Python will make a local copy of the installed Python in your home directory. Now you want to make sure you execute this next command with the newest version of Python available on your host. For example, Site5 offers both Python 2.3.4 and Python 2.4.3. We want to use Python 2.4.3. To verify the version of your Python, execute the following command:
python -V
If that displays Python 2.3.x or anything earlier, try using python2.4 -V or python2.5 -V instead. Whichever command renders the most recent version of Python is the one you should use in place of python in the next command. Since python -V currently displays Python 2.4.3 on my Site5 sandbox, I will execute the following command:
python ~/downloads/virtual-python.py
Again, this is just making a local copy of the Python installation that you used to run the virtual-python.py script. Your local installation is likely in ~/lib/python2.4/ (version could vary).
To reduce confusion and hassle, let's give our new local installation of Python precedence over the system-wide Python. To do that, open up your ~/.bashrc and make sure it contains a line similar to this:
export PATH=$HOME/bin:$PATH
If you're unfamiliar with UNIX-based text editors such as vi, here is what you would type to use vi to make the appropriate changes:
Once you've made the appropriate changes to ~/.bashrc, you need to make those changes take effect in your current SSH session:
source ~/.bashrc
Now we should verify that our changes actually took place. Type the following command:
which python
If they output of that command is not something like ~/bin/python or /home/[your username]/bin/python, something probably didn't work. If that's the case, you can try again, or simply remember to use ~/bin/python instead of python throughout the rest of this HOWTO.
Now we should install Python's setuptools to make our lives easier down the road.
cd ~/downloads wget http://peak.telecommunity.com/dist/ez_setup.py python ez_setup.py
This gives us access to a script called easy_install, which makes it easy to install many useful Python tools. We will use this a bit later.
Let's now download the most recent development version of Django. SSH into your account and execute the following commands (all commands shall be executed on your host).
svn co http://code.djangoproject.com/svn/django/trunk ~/downloads/django-trunk
Now we should make a symlink (or shortcut) to Django and put it somewhere on the Python Path. A sure-fire place is your ~/lib/python2.4/site-packages/ directory (again, that location could vary from host to host):
ln -s ~/downloads/django-trunk/django ~/lib/python2.4/site-packages ln -s ~/downloads/django-trunk/django/bin/django-admin.py ~/bin
Now verify that Django is installed and working by executing the following command:
python -c "import django; print django.get_version()"
That command should return something like 1.0-final-SVN-8964. If you got something like that, you're good to move onto the next section. If, however, you get something more along the lines of...
Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named django
...then your Django installation didn't work. If this is the case, make sure that you have a ~/downloads/django-trunk/django directory, and also verify that ~/lib/python2.4/site-packages actually exists.
In order for your Django projects to become useful, we need to install some other packages: PIL (Python Imaging Library, required if you want to use Django's ImageField), MySQL-python (a MySQL database driver for Python), and flup (a utility for fastcgi-powered sites).
easy_install -f http://www.pythonware.com/products/pil/ Imaging easy_install mysql-python easy_install flup
Sometimes, using easy_install to install PIL doesn't go over too well because of your (lack of) permissions. To circumvent this situation, you can always download the actual PIL source code and install it manually.
cd ~/downloads wget http://effbot.org/downloads/Imaging-1.1.6.tar.gz tar zxf Imaging-1.1.6.tar.gz cd Imaging-1.1.6 ln -s ~/downloads/Imaging-1.1.6/PIL ~/lib/python2.4/site-packages
And to verify, you can try this command:
python -c "import PIL"
If that doesn't return anything, you're good to go. If it says something about "ImportError: No module named PIL", it didn't work. In that case, you have to come up with some other way of installing PIL.
Let's attempt to setup a sample Django project.
mkdir -p ~/projects/django cd ~/projects/django django-admin.py startproject mysite cd mysite mkdir media templates
If that works, then you should be good to do the rest of your Django development on your server. If not, make sure that ~/downloads/django-trunk/django/bin/django-admin.py exists and that it has a functioning symlink (shortcut) in ~/bin. If not, you'll have to make adjustments according to your setup. Your directory structure should look something like:
Now we need to make your Django project accessible from the Web. On Site5, I generally use either a subdomain or a brand new domain when setting up a Django project. If you plan on having other projects accessible on the same hosting account, I recommend you do the same. Let's assume you setup a subdomain such as mysite.mydomain.com. On Site5, you would go to ~/public_html/mysite for the next few commands. This could differ from host to host, so I won't go into much more detail than that.
Once you're in the proper place, you need to setup a few things: two symlinks, a django.fcgi, and a custom .htaccess file. Let's begin with the symlinks.
ln -s ~/projects/django/mysite/media ~/public_html/mysite/static ln -s ~/lib/python2.4/site-packages/django/contrib/admin/media ~/public_html/mysite/media
This just makes it so you can have your media files (CSS, images, javascripts, etc) in a different location than in your public_html.
Now for the django.fcgi. This file is what tells the webserver to execute your Django project.
And finally, the .htaccess file:
RewriteEngine On RewriteBase / RewriteRule ^(media/.*)$ - [L] RewriteRule ^(static/.*)$ - [L] RewriteCond %{REQUEST_URI} !(django.fcgi) RewriteRule ^(.*)$ django.fcgi/$1 [L] |
The .htaccess file makes it so that requests to http://mysite.mydomain.com/ are properly directed to your Django project. So, now you should have a directory structure that something that looks like this:
If that looks good, go ahead and make the django.fcgi executable and non-writable by others:
chmod 755 ~/public_html/mysite/django.fcgi
After that, head over to http://mysite.mydomain.com/ (obviously, replace the mydomain accordingly). If you see a page that says you've successfully setup your Django site, you're good to go!
I've noticed that I need to "restart" my Django sites on Site5 any time I change the .py files. There are a couple methods of doing this. One includes killing off all of your python processes (killall ~/bin/python) and the other simply updates the timestamp on your django.fcgi (touch ~/public_html/mysite/django.fcgi). I find the former to be more destructive and unreliable than the latter. So, my advice is to use the touch method unless it doesn't work, in which case you can try the killall method.
Good luck!
There are a lot of exciting changes happening with Django right now. A lot. Some of these changes cause a lot of things to break across my sites. One such change was the integration of Thejaswi Puthraya's Summer of Code project: an improved comment system.
The first, and most obvious problem, was the change in the URLconf. This took me a while to track down for one reason or another. Here's the situation: originally, the django.contrib.comments application used a URLconf such as:
(r'^comments/', include('django.contrib.comments.urls.comments')),
This makes any comments-powered pages blow up. To solve this particular problem, just make it:
(r'^comments/', include('django.contrib.comments.urls')),
The next thing that caught me dealt with the templates for comments. Now there are actually some default ones, which is nice, but they might interfere with your own templates. I found that all I need in my templates/comments/ directory now is a single simple template called base.html:
{% extends 'base.html' %}
All of the other templates aren't needed unless you do some customized stuff (which I don't bother with).
Finally, and probably the most frustrating of all, getting an error such as:
NoReverseMatch: Reverse for '<function post_comment at 0xb504a1b4>' not found.
I'm not really sure why this problem has arisen, but my solution for it is to remove the entire django/contrib/comments/ directory and bring it back down from SVN. My guess is that some .pyc file lingering from the original comments application is interfering with the new comments application.
Feel free to post here if you have any other advice or problems!