I ran into this bug tonight working on a project where I was making use of ContentTypes and realized that there were a bunch of expected ones missing. I quickly got the sinking feeling that this was a major bug in nashvegas so I set about to isolate and find the root cause so that I could fix it.

I opened up the Django source code and took a look at what the syncdb command was doing as when I ran syncdb all the ContentType objects were created properly. I quickly noticed this code in the handle_noargs method:

# Import the 'management' module within each installed app, to register
# dispatcher events.
for app_name in settings.INSTALLED_APPS:
    try:
        import_module('.management', app_name)
    except ImportError, exc:
        # This is slightly hackish. We want to ignore ImportErrors
        # if the "management" module itself is missing -- but we don't
        # want to ignore the exception if the management module exists
        # but raises an ImportError for some reason. The only way we
        # can do this is to check the text of the exception. Note that
        # we're a bit broad in how we check the text, because different
        # Python implementations may not use the same text.
        # CPython uses the text "No module named management"
        # PyPy uses "No module named myproject.myapp.management"
        msg = exc.args[0]
        if not msg.startswith('No module named') or 'management' not in msg:
            raise

It was now clear to me that none of the signals could have been getting registered since the nashvegas management command didn't import much at all. I took a quick look at the django.contrib.contenttypes app to validate my theory that it did in fact operate on a post_syncdb signal. Sure enough, there in django.contrib.contenttypes.management was:

signals.post_syncdb.connect(update_contenttypes)

However, just putting that "hackish" block of code in the nashvegas init_nashvegas method wasn't going to cut it all the time, as I noticed that when it was detected that there weren't any migrations to execute, I bailed early, instead of continuing to at least emit the signal like syncdb does. So, I quickly made that fix and bumped the version number and pushed out a new release.

In the past, most incremental releases to nashvegas have been about adding bits of added functionality. This is the first time I have to address a fairly critical bug and it's a bit embarrassing to say the least. I hope that this resolves any issues you might be having with it -- you may be seeing odd behavior and not immediately realize it's due to this problem.

Please let me know if you are still having any issues after applying this release either through the github issue tracker or on Freenode in the

nashvegas channel.