On Thu, Sep 19, 2013 at 9:41 PM, Marc Tamlyn <marc.tam...@gmail.com> wrote:
> The problem you've got here is how it knows to *not* install EmailUser. If > it's a model defined in d.c.auth.models, it will get installed, > irrespective of whether it is AUTH_USER_MODEL or not. This is where we have > to special case the new model somehow so it is only installed if we are > using it. This is far from straightforwards! By putting it in a separate > app which is not installed by default, then we solve this issue trivially > without more magic. > Elaborating on this point: it's not just the models, either -- it's views, admin registrations, forms, and potentially URLs. There's also a matter of consistency. We have to ship a default User model. We've set up a system that encourages people to develop their own user models. If you develop a third party User model, you need to do two things -- register the app, and declare AUTH_USER_MODELS. It seems completely logical to me that an EmailUser app that we're shipping as part of Django should be expected to do the same. If nothing else, it means we can point at contrib.email_auth and say "that's how you do it!". > On 19 Sep 2013 05:27, "Luke Sneeringer" <l...@sneeringer.com> wrote: > >> Bah, I should have planned my e-mailing better. Sorry for sending a third >> in such rapid succession. >> >> I just did some checking into my assumptions (quoted below) on this. It >> turns out that Django core already does some of what I suggest: in >> particular, it doesn't install the User model if django.contrib.auth is >> installed but another AUTH_USER_MODEL is invoked, based on a Meta option >> called "swappable" (see [here][1] and [here][2]). >> >> Am I misunderstanding? It seems like we are already pretty well down my >> proposed path. >> > You've correctly identified the current behaviour, but you're extrapolating in a direction that isn't possible (at least, not with the current infrastructure). You're correct in saying auth.User won't be installed if another model is set as AUTH_USER_MODEL. However, if auth.User (or any other model for that matter) is set as AUTH_USER_MODEL, nothing prevents EmailUser from being installed. This is because there's no artefact on the "plugged" model that says "I'm a candidate for being a pluggable User. *Any* model *could* be installed as a User -- you don't have to predeclare "I'm a candidate for being a User". Therefore, we have no metadata basis on which to say "Oh, I'm not being used as a pluggable model, don't install me." We *could* add this metadata, but again -- we'd be adding metadata and a bunch of complex internals as a workaround for asking users to put an app in INSTALLED_APPS, and set AUTH_USER_MODEL. For my money, the cost vastly exceeds the questionable benefit. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
