Hi Luke - I just wanted to clarify the approach I'm using - The issue of whether or not the EmailUser is in contrib.auth or in a new app contrib.auth_email is a separate issue from code duplication. Either way, you'd have to create new versions of UserCreationForm, UserChangeForm, UserAdmin, and UserManager, because each of those classes will only work with the default auth.User model (as currently written).
So there's really two independent questions at play here: 1) Should a new EmailUser model be in contrib.auth or contrib.auth_email? Based on the current recommended way to use swappable, EmailUser should be in its own app contrib.auth_email. This could be changed by "blessing" the usage of swappable that Aaron was talking about (which does seem to work), in which case EmailUser could be in the contrib.auth app without conflicts. Testing would have to be done to make sure this works in all cases. 2) Should contrib.auth undergo refactoring to reduce the amount of code duplication required to create a custom user model? This would require modifying the two forms, admin class, and user manager to support custom models without further subclassing (except to add new functionality) or replacement. I did this for UserManager in my alternative patch ( https://github.com/tanderegg/django/compare/ticket_20824_refactor_master), which was fairly straightforward although a little awkard since the current public api requires a separate parameter passed to create_user for email, even if 'email' is also being used as the username. The forms and admin class would be a bit harder, it could be done but the result would probably be a bit convoluted, and they still would not cover all use cases of course. Better would be to create abstract base classes for those forms and UserAdmin that cover essential functionality, and then allow custom models to inhereit from those, which would reduce code duplication fairly substantially. If we used abstract base classes though, the custom user model would still require defining custom forms and admin classes as well, they would just be much simpler. -Tim On Fri, Sep 20, 2013 at 2:47 PM, Luke Sneeringer <l...@sneeringer.com>wrote: > > On Sep 20, 2013, at 10:58 AM, gavinw...@gmail.com wrote: > > > > No other User model needs to [set swappable] > > > > This would still be the case. Only models that want to conditionally > load themselves would set swappable. User models in application code > probably wouldn't set it, because the project will always use that one user > model. > > This is my understanding too. If you set a user model in individual > project code, there's no point in defining it as swappable, as that project > is always going to want to use it. > > If you're writing the authtools app, you probably do want to define the > user model or models you offer as swappable, but that seems like it's still > true now. > > > > ... made a special case of "Swappable models in the same app". > > > > I'm not sure where there's a special case. Swappable works for this > without any modifications, see authtools. > > > > > *Any* model can be swapped in as a substitute user. > > > > Yep. Nothing needs to change to keep this possible. > > > > > If we were to go down this path, the logical extension (to my mind) > would be to validate that you're not swapping in a model that hasn't > declared itself as swappable > > > > Why would you want to validate this? Swappable only controls loading of > the model its set on, there is no action-at-a-distance on other models. > > I, too, don't really understand this assumption. The status quo works just > fine, and makes complete sense to me. > > > I don't think we should focus so much on the optional part of the > proposal. The really important part is to refactor the existing code to > work better with custom users. Once this happens, projects like authtools > can trivially add an EmailUser in a few lines of code, so it's not so > important that there's one in core. > > Eh, I pretty passionately believe that this particular use case needs to > be in core. It's **really** common. But, the point that you make is why I > am passionate about not just making an auth_email app, because I see the > other approach as *also* having more value in simplifying some other > more-simple user substitutes. > > L > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/rb7v9kVAK3I/unsubscribe > . > To unsubscribe from this group and all its topics, 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.
