Providers use overly generic app names

[aehlke]

Using generic app names like "oauth", "facebook", "twitter" easily leads to conflicts with other apps. Django does not allow using the same app name, even if the app's path is different (it only considers the rightmost component). A lot of Django works, but some things fail, notably South migrations if you already have an app with migrations named the same as one of the allauth providers. In my case, our project has facebook and twitter apps already (my fault for naming them generically, but these aren't reusable components that I'm planning to open source, they're project-level apps).

I'm making a fork to rename all providers to e.g. facebook_provider, but I don't see how I can fix it for my case where I have to do this before even adding allauth at all to my project and also be able to migrate existing installs of allauth. I suspect it's not possible without backwards-compatibilty-breaking changes.

[pennersr]

I am aware of this issue and have been pondering about it for some time now. Pre/postfixing all providers does not feel right. Most of the providers are not true apps (in the sense that they offers models et al) anyway. OpenID is currently the exception. I was thinking more along the lines of dropping the use of apps alltogether -- move them into an INSTALLED_PROVIDERS or AUTHENTICATION_BACKENDS kind of setting. Then again, maybe this gets fixed in Django at some point in the future. Given that changing any of this is high-impact I want to give this some more thought...

[aehlke]

Having some kind of providers setting with python paths makes the most sense to me. You're right that they don't make sense as apps themselves. It would be great to see this happen before long - even if Django implemented this tomorrow, it takes a long time for people to migrate to the latest versions of it. Easier to migrate a lib than the entire framework. Thanks!

[acechase]

How have others been getting around this? I'm trying to upgrade from V0.8.2 to V0.18.0 and need to get the fb provider in play and I have a project-specific facebook app that is colliding on migrations.

On my local system I am currently experimenting with the following hack:

• comment out my facebook app from INSTALLED_APPS
• delete from south_migrationhistory where app_name = 'facebook';
• ./manage.py migrate allauth.socialaccount.providers.facebook
• ./manage.py migrate allauth.socialaccount
• uncomment my facebook app

Obviously a total hack, but seems to work okay so far... Curious if others have followed similar path and if there's any other pitfalls I should be looking out for.

[aehlke]

@acechase my solution was to fork allauth and rename the provider apps

[PiDelport]

Note: #993 has a bit more discussion about this.

[Bartvds]

This is still happening and kind of a pain when adding allauth to existing projects.

[iMerica]

What was the decision on this? I'm getting started with All Auth today and it seems like the only way I can use it is to fork the project and rename the account app.

[fazpu]

Opened in 2013..., adding allauth to existing projects hurts due to this issue.

[pavlo-mk]

have any ideas about when it will be solved? I used in my django app allauth, but have app named 'account' too.

[ishakoktn]

This was a painful experience. Please reprioritize this issue.

[jdeanwallace]

One way to workaround this issue is to make your conflicting Django app also look like an allauth provider. For example:

# facebook/provider.py

# To avoid app naming conflicts between allauth providers and our local apps,
# let's make our local app look like a specific allauth provider.
# https://github.com/pennersr/django-allauth/issues/393
from allauth.socialaccount.providers.facebook.provider import provider_classes

# example/settings.py

INSTALLED_APPS = [
    # ...
    "allauth",
    "allauth.account",
    "allauth.socialaccount",
    "facebook",
    # ...
]

This works because allauth goes looking for all modules called provider within each installed app, then tries to register their provider_classes (source).