But Django already has the mechanism to know not to install the model. It's the
"swappable" Meta option. That is what causes User not to be installed if it is
not used (contra my initial statement yesterday; I was flat wrong).
Right now, User has a meta option:
swappable = 'AUTH_USER_MODEL'
...that does exactly what we are describing. It seems EmailUser (or whatever we
call it) should just do this also.
> On Sep 19, 2013, at 7:41 AM, 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.
>
>> 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.
>>
>> Best Regards,
>> Luke
>>
>> [1]:
>> https://github.com/django/django/blob/b2b763448f726ee952743596e9a34fcb154bdb12/django/contrib/auth/models.py#L406-L414
>> [2]:
>> https://github.com/django/django/blob/master/django/db/models/loading.py#L296
>>
>>
>>> On Sep 18, 2013, at 10:03 PM, Luke Sneeringer <l...@sneeringer.com> wrote:
>>>
>>>> On Wednesday, September 18, 2013 6:39:13 PM UTC-6, Russell Keith-Magee
>>>> wrote:
>>>>
>>>>> On Thu, Sep 19, 2013 at 3:39 AM, Luke Sneeringer <lu...@sneeringer.com>
>>>>> wrote:
>>>>> I added the authtools approach to the wiki for completion, although I
>>>>> believe it to be an inferior approach.
>>>>>
>>>>> One thing I dislike is having a separate app (e.g. d.c.auth_email) that
>>>>> has to be installed separately. That feels pretty impure to me. I'm doing
>>>>> a thought exercise about potential solutions, though, and not exactly
>>>>> coming up aces.
>>>>>
>>>>> The best solution I can currently think of is to have User and EmailUser
>>>>> which are both models that live in django.contrib.auth. Then, we would
>>>>> have to add code to our model detection that says that *if* a model is a
>>>>> subclass of AbstractBaseUser, include it if and only if it is the
>>>>> AUTH_USER_MODEL.
>>>>>
>>>>> I can't decide if that solution is better or worse than the disease. It
>>>>> makes for a much more attractive set of steps to follow for people who
>>>>> want to use it, though -- basically, just set AUTH_USER_MODEL to
>>>>> 'auth.EmailUser', and done.
>>>>
>>>> My opinion - it's worse than the disease.
>>>>
>>>> Option 1 involves a clean auth app that just contains a stub user, and a
>>>> clean extension app providing an alternative user. You install the
>>>> extension app, and say you want to use it.
>>>>
>>>> Option 2 makes a special case of *one particular* extension user, and
>>>> makes all the internals of models, forms, views, etc embedded inside an if
>>>> statement.
>>>
>>> I think where I part from you is on the "one particular" aspect of the
>>> discussion. I actually see the "option 2" approach as having very clean
>>> side effects for some other use cases.
>>>
>>> Allow me to explain:
>>> There is, as you have pointed out, a lot more to auth than just the User
>>> model. There are forms and the like, which you mentioned, but there are
>>> also other aspects: the permissions models and functionality, for instance.
>>> Subclasses of AbstractBaseUser which also subclass PermissionsMixin still
>>> get the permissions things out of the box, and that is a documented use
>>> case in the official documentation.
>>>
>>> So, right now (if I understand correctly), if you install the auth app, you
>>> get the Group and Permission models (and supporting code, natch), as well
>>> as the User model. If you decide to set a different User model using
>>> AUTH_USER_MODEL, but you keep auth installed for these other aspects
>>> (Group, Permission, etc.) then Django installs an auth_user table that
>>> isn't used (note to self: verify this).
>>>
>>> If you set AUTH_USER_MODEL to something other than auth.User, you are
>>> making a statement that you do not want the stock model. This is true
>>> whether you change it to the upcoming, included "EmailUser" model, or to
>>> something else entirely.
>>>
>>> So, I don't think that option 2 "makes a special case of one particular
>>> extension user". If anything, I assert it would do the opposite: it
>>> actually performs the most expected behavior in all cases. If the plain
>>> User model is the AUTH_USER_MODEL and d.c.auth is in INSTALLED APPS, then
>>> it is installed. If you choose to use an included-in-core e-mail model and
>>> install d.c.auth, you get that model and table instead of the current User
>>> model. And, if you use your own, special custom User model, but install
>>> auth for the remaining aspects, then you get your custom user model, and
>>> not either of the stock ones.
>>>
>>> Basically, my understanding is that you start to get unclean and
>>> counter-intuitive behavior when you want to install the auth app for
>>> everything other than the User model (and forms, etc.), that this would
>>> correct.
>>>
>>> Best Regards,
>>> Luke
>>>
>>> P. S. To be clear, I am not trying in any way to be argumentative, and I am
>>> happy to implement the separate app if that is what the core developers
>>> decide on.
>>>
>>> --
>>> 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.
>>
>> --
>> 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.
>
> --
> 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.
--
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.
