Legend:

* Doesn't solve the analogous problem for any other project. E.g., contrib.comments already has pluggable Comments models, and has invented a bespoke solution. Other projects will have similar needs; this solution doesn't address the duplication of code.

102

102

* Has unpredictable failure modes if a third-party app assumes that User has a certain attribute or property which the project-provided User model doesn't support (or supports in a way different to the core auth.User model).

103

* Prone to unpredictable problems if `AUTH_USER_MODEL` is modified after the initial syncdb (i.e., someone changes the settings to change the User model, but doesn't document/alert anyone that a migration will be required). This might be able to be managed by introducing a management table to the database to track the syncdb-time value for the AUTH_USER_MODEL setting, and raising a validation error if the current setting value doesn't match the value in the table.

* Existing apps need to be updated to reflect the fact that auth.User may not be the User model. All instance of !ForeignKey(User) need to updated to !ForeignKey(settings.AUTH_USER). Failure modes will be unpredictable, as auth.User will still exist as a table, but won't contain any User information.

134

135

* Still has the settings-models circular dependency problem

136

* As with Solution 2, prone to unpredictable problems if `USER_MODEL` is modified after the initial syncdb.

* Doesn't address the immediate problem for !EmailField. We could do the same User/!SimpleUser conversion here; with the added benefit that we are also introducing App Refactor, so we can use the distinction between an "unconfigured" auth app and a "Django 1.5 App Refactor Configured" auth app as the point for identifying whether User or !SimpleUser is in use.

164

165

* As with Solution 2, prone to unpredictable problems if the app configuration is modified after the initial syncdb.