This feature was something we'd hoped would be awesome; it's not. Going over the documentation shows there's some jaw-dropping nastiness you have to go through to make it work.
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.
Can you expand on the "jaw-dropping nastiness you have to go through to make it work"? Seems pretty straightforward, though I have not tried to actually use it yet.
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).
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.
> there's some jaw-dropping nastiness you have to go through to make it work.
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"?
I've been using custom User models for over a month, and I can tell you that using a profile model is far nastier.
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.
Yeah I've been using them for about a month too and all I can say is, this is how it should have always been.
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.
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.