On Thu, Sep 19, 2013 at 8:37 AM, Aaron Merriam <aaronmerr...@gmail.com>wrote:
> Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL > to 'auth.EmailUser', and done". > > It'd be nice if 'swappable' could accomplish this for us. Something along > the lines of for any set of swappable models which are swappable for the > same settings value, only load the one that is named by the settings value. > I am taking some time to read the source surrounding this setting and > model loading to even figure out if this is a possible modification. > Russel, curious about your thoughts on if this approach would be something > you would sign off on. > Can't say I'm wild about it. Explicit is better that implicit. Regarding your technical suggestion -- I'm not sure I see how that would work. auth.User nominates itself as swappable; and then you use AUTH_USER_MODEL to point myauth.EmailUser as the new User. There's nothing on EmailUser itself to say "I'm intended for use as a swappable User model", so there's no way to do the retrospective "don't install me if I'm not AUTH_USER_MODEL". EmailUser is, in every respect, a "normal" Django model. We could add another Meta setting for this, I suppose, but that doesn't fix the problems with picking the right forms, admin registration, views, and so on. And we'd be adding that setting for one specific reason - so that you can have 2 user models in contrib.auth, and only have one installed in the app cache. The setting wouldn't be any use to anyone else developing a third-party User model, because they have to do things "the right way" - install and app, and point the user model at model in the app. If we were going to go down the "single setting" model, I'd rather see it as "you put auth_email in your INSTALLED_APPS, and that automatically sets AUTH_USER_MODEL". However, that requires infrastructure that we don't have at the moment. See my permanent refrain to App Refactor :-) And even then, I'm not necessarily convinced it's the right way to go. I don't see 2 explicit settings to be especially onerous, or difficult to explain. One setting installs the app. The other tells Django which model in that app to use. They really are separate concerns. Oh - and Russell, not Russel :-) > This seems like a good compromise over adding infrastructure for not > installing certain models. This would instead create infrastructure to > declare a certain 'type' of model must be present, but that you may decide > which one based on a settings value. > > This approach feels cleaner to me because we don't want to 'turn off' a > model, but rather only load a single 'User' model from some set of 'User' > models. In the case of 'User', we need at least one 'User' model to be > loaded, and this enforces that, where as the ability to turn off certain > models could introduce situations in which someone turns off a model > without replacing it. > Remember - It's not just about models. It's about forms, admin registrations, views, possibly even URLs. 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.
