> The intention was to mark a particular model as a something that can be replaced.
It's hard to find the original rationale behind swappable, but my mental model was always: A model with `swappable = 'x'` means that the model should only be loading if settings.x is set to that same model > it's still not desirable. Why not? Swappable seems like exactly what we need here. > 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. > ... 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. > Secondly, marking a model as swappable doesn't make it zero cost. That's fair. I'll add it to the wiki as a disadvantage. > So far, the only convincing argument I've heard for putting the EmailUser in contrib.auth is that it avoids having to add a value to INSTALLED_APPS. 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. -- 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.
