Tai, read https://gist.github.com/2289395 for a summary of many reasons why I think profiles are a bad idea, and unifying multiple profiles is an even worse idea.
Best, Alex Ogier On Fri, Apr 6, 2012 at 6:15 AM, Tai Lee <real.hu...@mrmachine.net> wrote: > Alex Ogier, > > Is it really better to require users to create their own User model that > behaves like an admin user, instead of just shipping with a self contained > admin user (as a profile model) without the auth component? > > If the auth app was purely a stub to connect different profiles and > authentication systems from different apps (or the project), but doesn't > actually define any identity or authentication or profile models itself > (not counting base abstract classes), isn't that effectively achieving the > separation that you want? Being able to use admin without the current cruft > in auth or with any completely different authentication credentials, and > similarly using any other pluggable app without any cruft needed by the > admin. > > In any case, I don't think it will actually be possible to use the admin > or any other pluggable app that relies on the concept of a central user who > might access to multiple apps (instead of every app having its own users > and auth) without *an* auth app and a central User model. > > Like Adrian, I don't actually use the User model for auth or identity > (name, email, etc.) anymore. But unless you have authored *all* the apps in > your project and they know how to talk to *your* User model, you still need > a User from Django, because that is what all 3rd party pluggable apps will > need. > > If I want to use any 3rd party apps that use the central user, I will > still need to create a Django User and fake or sync the that are only there > for the admin, even if I don't use the admin. If you still require swapped > in User models to assume a minimal interface and fields, people will still > have this problem. > > This is why I think the central User should not contain any auth or > identity data, so there is no cruft required only for apps you may not even > be using, and so you are not tied to any particular auth system. > > Cheers. > Tai. > > > On 06/04/2012, at 3:44 PM, Alex Ogier <alex.og...@gmail.com> wrote: > > 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. > > -- > 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.
