Last night I took a break from my most recent Django app, a mailing-list manager, to explore the new "Magic Removal Branch".
I diligently followed the instructions on the Django Wiki to change my existing code. There were more changes needed than I’d anticipated, but they all made sense, so I didn’t mind. Better, I agreed philosophically with all of them.
Basically, the idea is to make Django apps act more like normal Python modules. That means ceasing all the “magic”, where it used to automatically provide entire new classes to manage objects, and used to magically move around the modules, making them available in namespaces you hadn’t explicitly named. I found that confusing, to be honest. I always had to look at example code to find out where the magic stuff was going to be. The magic, which was supposed to be helpful, actually ended up costing me time and thought.
Roadblock 1 - Database Init
Unfortunately, I’m not all the way there yet in migrating my code. First, I ran into a significant problem with database initialization. That is, it didn’t work.
$ bin/admin.py initFile "/sw/lib/python2.4/site-packages/django/core/management.py", line 498, in init
contenttypes_app = models.get_app('contenttypes')File "/sw/lib/python2.4/site-packages/django/db/models/loading.py", line 30, in get_app
raise ImproperlyConfigured, "App with label %s could not be found" % app_labelImproperlyConfigured: App with label contenttypes could not be found
OK, I restored the old database. It was a good thing I backed up before trying this! I then executed the SQL recommended on the Wiki to convert an existing install to the new branch. That mostly worked, but complained that a few tables were missing. “django_flatpages”? Never used that one, I assume it was a contrib module.
Roadblock 2 - code changes
I think I’ve converted all the existing code correctly, but the server dies on start. Apparently, I did not convert my old "”Class META" to the new "Class Admin" correctly. I’m sure I’ll knock that problem down the next time I have a moment to tackle the conversion. Unfortunately, I ran out of time, exhausting the one hour I had left before “The Daily Show” last night.
Conclusions
Absolutely worth the pain. It will work with a little more tweaking. These are normal pains to experience when using a pre-release, actively developed branch.
Update: The contenttypes error is corrected by a patch available from bug #1280.
Technorati Tags: django, python, magic removal
















3 responses so far ↓
1 Django Magic Removal, this time for real - Coder’s Eye // Apr 27, 2006 at 12:18 pm
[…] Despite my earlier initial successes using the Django Magic-Removal Branch, I had to rollback. The branch code was stuck in an unusable state for a couple weeks when I was really wanting to crank out some functionality on my storefront. […]
2 Filtrar conteúdo da administração de acordo com o usuário « Django Django // Feb 28, 2008 at 3:45 am
[…] fazer ambos funcionarem sem criar muitos remendos no Django. Isso só funciona com magic-removal (deve haver algum modo de fazer no trunk, mas provavelmente será mais […]
3 Filtrar conteúdo da administração de acordo com o usuário at Django Django // Feb 29, 2008 at 9:06 am
[…] fazer ambos funcionarem sem criar muitos remendos no Django. Isso só funciona com magic-removal (deve haver algum modo de fazer no trunk, mas provavelmente será mais […]
Leave a Comment