On 09/03/12 09:37, Clay McClure wrote: > Who's talking about a migration? I'm asking for something that will work > for *new* installations; existing installations can continue > authenticating against usernames for all I care :) > > Moreover, I'm thoroughly frustrated by the fact that developers *do* > bring working solutions to the table (in the form of patches in trac), > but the core developers won't integrate them, either because it's not > the right time (usually right before a release), because the patch isn't > general enough, or because the patch doesn't meet some absurdly high bar > of quality. I understand that they have a commitment to backwards > compatibility and that accepting a mediocre patch could mean maintaining > it for life, but I like to think that—with a framework that purports to > be "pragmatic"—there are pragmatic solutions to these problems—and not, > "sorry, it's not perfect, it can't go in."
What you are really saying is this: being pragmatic means that we prioritise *your* immediate need above the need to keep the code and the docs maintainable, and above the need to maintain compatibility with existing installations. There are a million-and-one hacks we would add if we took that approach, and Django would have a million-and-one more bugs, or possibly much worse - if you add just 10 boolean switches like the one you suggested in an earlier email, you've got over 1000 combinations to test and debug. The only way to avoid that in a framework like Django is well defined APIs for components. No-one has brought such a thing to the table and seen it through, that's why it hasn't come in. I believe that all the problems you have can be solved already: - you can write your own authentication backend to authenticate by email - you can write your own login and account creation views - you can even override admin views by inserting items into urls.py Yes, these are all more-or-less hacky. And they have problems. For instance, what if you have two accounts with the same email address? (I have that in some of my Django projects, BTW). The current code allows it, so we can't change anything that would make it impossible, at either the DB level or the Python level. This is the kind of issue that means you can't just use the existing models. A full and correct solution that didn't introduce dozens of new bugs is quite hard - and I'm talking about just the code required to fix this one feature for you, without doing anything more generally useful. That is why we're not going to put hacks like this in core - we would have to support these hacks for at least 3 versions if we did. We are interested in *removing* existing hacks from our code base, and this is vital if Django is going to see increases in features and functionality. We are not interested in adding more hacks. We also will refuse to litter our documentation with things like: "if you've got this setting, it does this, otherwise you get this other behaviour, and you've got to watch out for all these bugs because this is a gross hack". > The GSoC page > (https://code.djangoproject.com/wiki/SummerOfCode2011#Enhancedauth.user) > is a frustrating read. It goes on and on about how hard the problem is > and how wrong your solution is, but doesn't provide any detail as to why > it's hard or why it's wrong. It does provide detail - it gives a list of issues you have to consider, and tells you where to search for the other issues. Some examples from a quick Google groups search for "auth User": http://goo.gl/swTpr http://goo.gl/fFlKh These provide a lot of detail. > Ticket #3011 was rejected without much of a > reason. HM asked for an explanation both in the ticket itself and on > django-dev; no explanation was ever given. I don't know what thread you are talking about. Hanne Moa brings up the subject here and gets two replies from Russell: http://goo.gl/7p1JN Regards, Luke -- "I imagine bugs and girls have a dim suspicion that nature played a cruel trick on them, but they lack the intelligence to really comprehend the magnitude of it." (Calvin and Hobbes) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
