Did you read the reasons that James decided to stop maintaining it? http://www.b-list.org/weblog/2013/aug/26/catching/
Any Django site that uses a database will benefit from integrating database migrations. On the other hand, there are many ways to do user registration (as James described in his post) so django-registration isn't a 90% use case that qualifies for inclusion in contrib. On Friday, August 1, 2014 9:02:54 AM UTC-4, Robert Grant wrote: > > Hi Tim > > Thanks for the reply. I'd say that it's only been viable so far because > James created and maintained it (for most of that long time), it's only > been a year since then and Django is pretty stable around users and > authentication. And even then people have forked the thing to Github to > create ad-hoc compatible versions for 1.6, because it's a very important > package. However, this isn't a stable situation; it was once, but now is > going to decay without proper maintenance. > > The reason why I think it should be pulled into contrib is because > registration goes hand in hand with changes to the way users and > authentication work in Django, and keeping the two in lockstep should be > relatively simple for those with an intimate knowledge of that part of > Django. Additionally, I think it's a key reason why people use Django, and > protecting features like that is important. > > Lastly, regarding the trend. South has been viable as a third party tool > for a long time, and has said "buck you" to the trend and made it all the > way into core. Which is great, because it means Django competes at the > highest levels in ORM, and that's another key reason to use Django. > > I suppose what I'm saying is that not everyone uses Django for love or > loyalty, or at least not to start with, and you have to pick which things > to maintain as its strengths and which to let go of to the community. > Coming from the outside, but having a fair amount of technology dev, design > and decision experience, I'd say having proper users and authentication > makes for a big, fairly rare distinguishing feature, and reliable > registration capabilities are an important complement to that. > > > On Friday, 1 August 2014 13:25:25 UTC+2, Tim Graham wrote: >> >> If no one has volunteered to maintain it in nearly a year since James >> stepped down, I think you'll have a tough time convincing us it's important >> enough to move into contrib. Also, the recent trend has been to remove >> things from contrib (comments, localflavor, formtools soon). >> django-registration has been viable as a third party package for a long >> time and I don't see a reason it couldn't continue as one. >> >> On Friday, August 1, 2014 7:07:19 AM UTC-4, Robert Grant wrote: >>> >>> Hello all >>> >>> I've just started using Django for a serious project and am really >>> enjoying using it; thank you. >>> >>> I'm using Django 1.6 and Python 3.4. For user signups, everyone >>> recommends using django-registration. However this is not under active >>> development >>> <https://bitbucket.org/ubernostrum/django-registration/wiki/Home> >>> (still works with a small code change) and as a budding Djangoer that >>> worries me twice: >>> >>> 1) as a developer, it makes my job much easier if standard functions are >>> provided. This is one of the (only) advantages of expensive corporate >>> tools; things such as registration and user management are well thought >>> through. >>> 2) as a Django fan (edjangalist?) I can already see that one of Django's >>> big advantages is that decent user management comes built in. However it's >>> not complete, and django-registration plugs a big hole, as most websites >>> will need this feature. Without it the user side of things becomes less >>> useful. >>> >>> Here's my proposal: >>> >>> Create a django.contrib.registration package. >>> Pull into it the existing django-registration code and update it to work >>> with the latest version of Django. >>> Keep it tightly in sync with changes to django.contrib.auth in the >>> future. >>> Add more flexibility, e.g. corporate options such as perhaps an admin >>> user can input email addresses of people to sign up, and the system >>> generates basic unactivated profiles that when triggered allow the users to >>> then fill in their remaining details (for example, this is how JIRA works). >>> And/or autodiscovery of users from LDAP settings and autopopulation of user >>> models from LDAP queries. This may be too unfocussed for the team though; >>> it's just a very nice to have! >>> >>> Anyway, that's my idea. I'm worried that as over time >>> django-registration drifts farther from the current version of Django, the >>> amount of work developers have to do every time will increase to the point >>> where it's better for them to roll their own than try and work out how >>> Django 1.5 worked with django-registration and what they need to do to >>> patch the differences. This will lead to developers - who are attracted to >>> Django because of useful stuff such as this - abandoning the platform for >>> ones that provide benefits in other areas. >>> >>> Thanks for reading >>> >>> >>> Robert Grant >>> >> -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/503a1c1c-612c-4fca-812c-b9d76a6f650d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
