Hi Daniel, On 03/15/2012 11:48 AM, Daniel Sokolowski wrote: > The issue here is that django auth is limited, and restrictive and needs > hacks to make it use emails as usernames, we can agree on that yes?
Certainly. > We > can also agree that contrib.auth2 with LFK is a complex undertaking far > into the future?. It is not a simple undertaking. How far into the future it is depends entirely on whether someone who wants to see it happen takes it upon themselves to make it happen. > Can we also agree that the 30 character limitation on > the username ought to be increased? I am not sure whether this should happen as a separate step or not. In an ideal world, we would have a longer username field. In the real world, we have to balance the benefit against the cost, and requiring a schema migration from practically every Django installation on the planet would IMO be the most significant backwards-incompatible change Django has ever shipped, at least since Django 1.0. It is not at all clear to me that the status quo, bad as it is, is worse than this cure. The cost would be mitigated somewhat if we had schema migrations in core, which would make the upgrade instructions much simpler and more foolproof. The cost would be reduced even more if we simply shipped this as part of a larger customizable-auth change (which will probably require at least a deprecation path itself). So, in my opinion, your energies would be more productively directed towards helping make one of those latter two things happen. But feel free to work on a proposal to simply change the field length. If you can provide a patch with a really compelling backwards-compatibility story, my mind is certainly open to change. Carl
signature.asc
Description: OpenPGP digital signature
