Firstly, thanks for your work on django-registration; I've been using it since 2009 and I've honestly lost track of the amount of time it has saved me over countless projects.
Secondly, this pull request relates more to the issue rather than the code itself; the code works and you are more than welcome to use it directly but I realise you might want to take a different path with it.
The problem: as it stands, registration/models.py includes a module level call to get_user_model if the method is available to import (as it would be when running against Django 1.5). Unfortunately, when using a custom defined auth model set in the normal way by using the app_name.model_name value for the AUTH_USER_MODEL setting, we can get circular import errors of the type:
"ImproperlyConfigured: AUTH_USER_MODEL refers to model 'users.User' that has not been installed"
This is due to how Django's app loading code currently works (I believe this is being worked on); calling get_user_model during initialisation before the custom user model has actually been loaded makes the whole thing explode.
The solution is to 1) lazy link Foreign Key fields by using strings instead of actual imports - this is recommended in the Django documentation & more importantly 2) to replace calls to User with run-time imports as opposed to init time imports.
NB: this only happens when you either include 'registration' in the INSTALLED_APPS setting or when you import from registration/models.py (e.g to subclass RegistrationProfile and swap out the Manager it uses).
Happy to do any extra code tweaking or answer any questions on this.
p.s If everyone else could please refrain from 'approving' or 'accepting' this pull request that would be cool, from past experience it does not help in any way except to spam James with emails and I've noticed a few declined pull requests over the whole 1.5 issue declined due to that. Cheers.
James has already made the call/design decision that the base views and forms will not work with custom user models as they are designed to work with the built in model and a custom model can't guarantee the correct logic. If you wish to use them, I believe the current suggestion is to subclass them and override for your own logic.
This pull request is related to the location of the get_user_model call causing issues and that alone.
I'm using Django 1.5 and a custom user model; how do I make that work?
Although the two built-in backends supplied with django-registration both assume Django's default User model, the base view classes are deliberately user-model-agnostic. Simply subclass them, and implement logic for your custom user model..