syncdb confuses any app named auth with its own

[dean@…]

I created an app called 'auth' which included some very, very simple auth type stuff. I have the django.contrib.auth removed from my INSTALLED_APPS since I do not need it. However, upon running syncdb, all of the django.contrib.auth tables are created even though they are not needed:

Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table auth_message

The work around for this is to rename the app. Once I renamed it to 'site_auth', these tables were no longer created during syncdb.

[Russell Keith-Magee]

It's entirely possible that this is happening; however, all the causes that I can think of stem from some level of user error. The most likely cause would be that something else in your stack is importing Django's auth app -- the admin would be the most likely candidate, but there are other possibilities.

Therefore, I'm going to mark this as needsinfo because there isn't enough information to reproduce the problem reliably.

[anonymous]

That would make sense if changing the name of the app didn't fix the problem. I have disabled all apps in my settings.py file except for my site_auth app.

It is not difficult to reproduce this problem and I have done it from a fresh project with django 1.3.

1. Run: django-admin.py startproject temp
2. Edit settings.py and comment out all apps under INSTALLED_APPS and all MIDDLEWARE_CLASSES
3. Run: ./manage.py startapp auth
4. Edit settings.py and add 'temp.auth', under INSTALLED_APPS
5. Run: ./manage.py syncdb
6. Notice the django.contrib.auth tables have been created.
7. Remove tables/database to start over
8. Rename auth project to s_auth (or anything other than just 'auth')
9. Edit settings.py and change INSTALLED_APPS to reflect this change
10. Run: ./manage.py syncdb
11. Notice that the django.contrib.auth tables are not created this time.

[Ramiro Morales]

This could be another manifestation of #16283. It reported similar undesired side effects thad had been introduced in r14563 (part of the 1.3 development cycle). That change got reverted in r16481 for the 1.3.X post-1.3 fixes-only SVN branch.

Please if you can test again with a fresh checkout of the 1.3.X branch.

[Aymeric Augustin]

Indeed, this looks exactly like the problem described in #16283.

I'm going to close the ticket, but please reopen if it's a different issue.