And it was reverted with https://github.com/django/django/pull/7410 because
of a link to ContentType.
I've recently run into this (as an infrequent user of Django) with a custom
backend and middleware that I'd like to keep reusable by using the standard
login and authenticate methods. I'm also using a custom user model, and so
cutting the link to the auth app makes sense.
It seems like a cleaner way to tackle this is to separate out the reusable
classes and functions from the auth app functionality, but that comes back
to Matt's first question: is that something we want to support?
Mark
On Sunday, 28 August 2016 09:43:36 UTC+1, Aymeric Augustin wrote:
>
> On 23 Mar 2016, at 01:57, Matt <ma...@satchamo.com <javascript:>> wrote:
>
> > I like to use the authentication machinery in Django, without explicitly
> putting 'django.contrib.auth' in INSTALLED_APPS. This prevents a bunch of
> unused tables from being creating in the database.
>
>
>
> Hello,
>
> For the record, we came to the following resolution on the related Trac
> ticket:
>
> MIGRATION_MODULES = {
> 'auth': None
> }
>
> This trick also works for django.contrib.sessions if you don’t use the
> database or cached database backend.
>
> --
> Aymeric.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/aa1d4c7f-c4b3-465b-9927-7a7c3a3c6f70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
