It's very easy to extend the existing user model rather than creating one from scratch. I had to do some unconventional auth stuff recently and I only extended auth.User slightly (and also wrote a slightly modified authentication backend).
It's good that they're providing it, but I think the complexity is going to turn people off (I know I won't be using it unless it's simplified at some point in the future). User profiles have always been used for adding data to User models indirectly, and I think this is probably going to remain the best way to handle it for most uses.
https://docs.djangoproject.com/en/1.5/topics/auth/customizin...
It appears the database migration is the biggest hurdle, but I don't think there's a way around that. User profiles require a join and that can be suboptimal, which is why this is a useful addition. If you weren't running into problems before it's probably better to not change (though that's usually the case for working code).
1) Setup custom user model to inherit from AbstractUser with no additional fields.
2) Meta.db_table = 'auth_user' on custom user model
3) schemamigration --auto
4) migrate --fake (alternatively comment out statements in migration file and run without fake)
Now you can add new fields or change the inheritance to AbstractBaseUser and south will follow along.
I just wanted to add one field to the user model, but to do that I had to add 100+ lines of code.
I am very happy custom User models are possible now––but for most stuff I'll probably keep using a UserProfile.
Besides avoiding a join in the DB (or worse, a separate select), being able to override user model methods has been an incredible benefit to my projects.
The docs give you a pretty good starting point for a fully functional user model, and jarcoal (above) outlines a simple method for migrating from old to new.
What "jaw-dropping nastinesses" are those, and why didn't you check and report them during the beta/rc phase since you were "hoping it would be awesome"?
Maybe this would be a nice way to contribute to Django...
[I'm a Django committer, FWIW.]
I suspect this may be the nastiness that's being referred to; this is the use case that I was hoping would be made dead simple.
With previous versions of Django I generated a random hash for use as a dummy/unguessable username, required an email address in the RegistrationForm, customized the AuthenticationForm, created a custom email authentication backend, and monkey patched User with various helper methods.
In 1.5 it looks like the AuthenticationForm will adapt to the field defined in USERNAME_FIELD[1], but a lot of work is still required. Support for easily using email address as the username (or support for easily specifying the username field in general without requiring all the other boilerplate) would probably go a long way.
[1] https://docs.djangoproject.com/en/dev/topics/auth/customizin...