> > However, if auth.User (or any other model for that matter) is set as > AUTH_USER_MODEL, nothing prevents EmailUser from being installed. >
The current behavior of swappable is that if two models are swappable on the same settings value, only the one designated by the settings value will be installed. So, currently, in django if I add the concrete model EmailUser to django.contrib.auth.models with swappable='AUTH_USER_MODEL', and do nothing else, this model is not installed. If I reset my database and set my settings.AUTH_USER_MODEL to 'auth.EmailUser', then EmailUser will be installed and 'django.contrib.auth.User' will not be installed. This is the current behavior of swappable based on my testing. So there is no need for new internal mechanisms to control whether a model is installed or not, as that mechanism already exists within the current behavior of swappable. On Thursday, September 19, 2013 5:09:10 PM UTC-6, Russell Keith-Magee wrote: > > > On Thu, Sep 19, 2013 at 9:41 PM, Marc Tamlyn <marc....@gmail.com<javascript:> > > 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" <lu...@sneeringer.com<javascript:>> >> 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.
