manage.py syncdb throwing error due content_types

[crybaby]

I have django dev version 6941.

There seems to be a problem with manage.py line when I do python

'''manage.py syncdb''':
execute_manager(settings)

It creates the tables and but fails to populate initial data.

#!/usr/bin/env python
from django.core.management import execute_manager
try:

# This is for Dos Prompt Start up
    import  settings
except ImportError:
    import sys
    sys.stderr.write("Error: Can't find the file 'settings.py' in the
directory containing %r. It appears you've customized things.\nYou'll
have to run django-admin.py, passing it your settings module.\n(If the
file settings.py does indeed exist, it's causing an ImportError
somehow.)\n" % __file__)
    sys.exit(1)

if __name__ == "__main__":
    execute_manager(settings)

[joe@localhost mysite]$ python manage.py syncdb
Traceback (most recent call last):
  File "manage.py", line 15, in ?
    execute_manager(settings)
  File "/usr/lib/python2.4/site-packages/django/core/management/
__init__.py", line 272, in execute_manager
    utility.execute()
  File "/usr/lib/python2.4/site-packages/django/core/management/
__init__.py", line 219, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python2.4/site-packages/django/core/management/
base.py", line 72, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/lib/python2.4/site-packages/django/core/management/
base.py", line 86, in execute
    output = self.handle(*args, **options)
  File "/usr/lib/python2.4/site-packages/django/core/management/
base.py", line 168, in handle
    return self.handle_noargs(**options)
  File "/usr/lib/python2.4/site-packages/django/core/management/
commands/syncdb.py", line 95, in handle_noargs
    emit_post_sync_signal(created_models, verbosity, interactive)
  File "/usr/lib/python2.4/site-packages/django/core/management/
sql.py", line 489, in emit_post_sync_signal
    verbosity=verbosity, interactive=interactive)
  File "/usr/lib/python2.4/site-packages/django/dispatch/
dispatcher.py", line 358, in send
    sender=sender,
  File "/usr/lib/python2.4/site-packages/django/dispatch/
robustapply.py", line 47, in robustApply
    return receiver(*arguments, **named)
  File "/usr/lib/python2.4/site-packages/django/contrib/contenttypes/
management.py", line 21, in update_contenttypes
    content_types.remove(ct)
ValueError: list.remove(x): x not in list

I have commented out this from settings.py,
#'django.contrib.contenttypes',

and syncdb and fixtures are working.

I am currently running python 2.4.3 on Fedora 6 and django svn revision # 6980.

[Jacob]

I can't reproduce this. Please post more info if you're still having this problem.

[lakin.wecker@…]

My friend reproduced this recently on Mac OSX, 10.4 python 2.5 using an sqlite3 database and django trunk r7639. I have the copy of the code that produces it. The core issue is strange, but is due to [source:django/trunk/django/contrib/contenttypes/management.py#L11 django.contrib.contenttypes.management]

    ContentType.objects.clear_cache()
    content_types = list(ContentType.objects.filter(app_label=app.__name__.split('.')[-2]))

Apparently, the first call to objects.filter after a clear_cache() call will always return an empty list (even tho there are actually content_types in the database.) Duplicating the filter call (one right after the next) will fix the issue ... _or_, commenting out the clear_cache will also fix it. I suspect there is an underlying bug in the QuerySet caching on OSX and sqlite3. But I can't be totally sure. Given some guidance I'd be glad to try to track down the issue, but I don't have OSX in front of me right now.

[lakin.wecker@…]

On the other hand, he may have a screwy python install. We're now seeing other wierdness from his django/python install and will be investigating it. Please feel free to re-close this ticket. If and when we figure out what's wrong we'll update here.

[Russell Keith-Magee]

Closed by request.

[lakin.wecker@…]

So, my friend re-installed python from a binary and it seemed to clear up this issue for us.

[lakin.wecker@…]

And apparently the python binary was 2.5.2, and he was running 2.5.1 when the problems were occuring.

[mpcabd]

I'm currently using Python 2.6 with Django 1.0 with MySQL 6.0.4 on a Windows XP and having the same problem.
I know I shouldn't use Windows but I'm developing on it now for a short period of time. :)

[Russell Keith-Magee]

The original report was caused by a messed up Python install. If you're seeing "the same problem", then you also have a messed up Python install, and there's not much we can do. If you're seeing the same error message, it may not be the same cause, in which case you should open a new ticket with a complete set of instructions for reproducing the problem.