Hi Aaron,

The motivation? Simple practicality.

contrib.auth ships with a known manifest of models. If you add extra User
models to contrib.auth, *every* Django project in existence will  gain
extra User models -- unless we develop a whole lot of extra infrastructure
to *not* install certain models.

Putting the "email-User' model in a separate app should mean it's a 2-line
configuration to opt into a "standardised" email-based User model, and no
special "don't install this model" infrastructure will be required.

As for the argument that there will be code duplication -- there shouldn't
be. A contrib email-auth app isn't going to *replace* contrib.auth.
contrib.auth has to be there for all the AUTH_USER_MODEL stuff to work.
There might be a need for some refactoring of contrib.auth to provide
better extension points, but we certainly aren't going to be reproducing
the entirety of contrib.auth in contrib.emailauth -- emailauth will be
extending the base provided by auth.

Yours,
Russ Magee %-)

On Wed, Sep 18, 2013 at 5:08 AM, Aaron Merriam <[email protected]>wrote:

> Russel, I'm curious if you could expand/explain your motivation on having
> this implemented as a separate contrib application rather than including it
> with django.contrib.auth
>
> On Thursday, September 12, 2013 5:41:29 PM UTC-6, Russell Keith-Magee
> wrote:
>
>>
>> On Fri, Sep 13, 2013 at 4:44 AM, Abdulaziz Alfoudari <
>> [email protected]> wrote:
>>
>>> This is a continuation of my post on 
>>> stackoverflow<http://stackoverflow.com/questions/18769729/django-removing-username-from-user-model>
>>> .
>>>
>>> With the introduction of Django 1.5, it was possible to create a custom
>>> User model which is flexible enough to have any user profile the developer
>>> wants created. However, looking at a very common problem which is using the
>>> email as the primary user identifier instead of username, the solution
>>> requires copying most of Django's internal definition of AbstractUser and
>>> that is only to remove the username field.
>>>
>>> A better solution in my opinion is make AbstractUser even more abstract
>>> by removing username field, and allowing the developer to explicitly
>>> specify the field to be used as the user identifier. This will require a
>>> tiny extra work for those that use the current default behavior, but it
>>> will also greatly reduce the work needed for the very common problem of
>>> using email as the user identifier.
>>>
>>> Please share your thoughts and opinions on this.
>>>
>>
>> The short answer: this isn't going to happen. AbstractUser is a released
>> and documented API, so we're not in a position to change it in the way you
>> describe without causing massive inconvenience to everyone that is using it
>> at present (at least, I don't see an obvious way that this could be done).
>>
>> However, ticket #20824 describes a proposal to add an email-login analog
>> of Django's built-in user. This would make introduction of email-based
>> login a matter of 2 lines of configuration. This ticket is really just
>> waiting on someone to prepare a patch… and it should be a relatively simple
>> patch to prepare. If you're looking to get involved in Django development,
>> this would be an easy place to start.
>>
>> 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 [email protected].
> To post to this group, send email to [email protected].
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to