I think this proposal will make more sense if people stop thinking "If someone wants to use contrib.auth, then why do we need another crufty interface to swap out auth.User?" Instead think of someone who wants to use contrib.admin but not be stuck with contrib.auth.
The point of this proposal isn't to make contrib.auth larger and better, it's to make it unnecessary. A lot of people find contrib.auth's models unsatisfactory. Adrian Holovaty stated that he hasn't used auth.User for several years. When you have a complex site with multiple authentication methods and requirements that don't fit django's idea of a user, it stops being worth it to bend yourself to django's will. The problem is that contrib.auth and contrib.admin are currently intimately linked. This proposal's purpose is to give an official way to break these two apart. I don't know of a single framework out there besides Django that ships with a fixed model for its users. The reason is that authentication and identity are radically different for every site so it's tremendously important to support whatever people decide to do, and not force decisions on them. So, stop thinking just in terms of contrib.auth.models.User. If you're already using that with a profile and it's all working fine, then this change isn't for you. This is for everyone who just wishes auth.User would go away without totally borking admin. Respectfully, Alex Ogier On Apr 6, 2012 1:21 AM, "Donald Stufft" <donald.stu...@gmail.com> wrote: > Nothing about this proposal prevents this. > > And in that case, no those 2 apps would not be able to be used together. > But this is hardly the first > time that 2 apps cannot be used together. because of choices made like > that on the app owner. > > On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote: > > I very much share Tai's concerns about the swappable user model > introducing incompatibilities. Imagine two apps, each of which requires an > "age" attribute on the user model. But suppose one of those apps expects > age to be the number of years since that user's birth and one of those apps > expects the age to be the number of years since the user registered for the > website. The user model must provide the same attribute to both apps, but > it is supposed to have a different value for each app. A developer will be > unable to use these two apps together without patching one of them. > > A bit of a contrived example, maybe, but I can imagine this > same-name-different-purpose issue coming up over and over again, making > otherwise pluggable apps incompatible with each other. > > I think we should go with a pared down user model and allow each app to > manage whatever data it needs on each user through profiles and signals. > Developers will end up with some data duplication, but I think that is > preferable to confusion about the source and purpose of data. Profiles are > essentially a way for each app to namespace its own data and I think that's > a good thing. > > Harris > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/p4jhylEp3x8J. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.