Hi Tim I did. I just reread it though; thanks for the link. There are multiple ways to do registration, agreed, but then one could - for example - make your same argument about logging into a system. Why provide that when some people might not want a site with authentication, or might want to do it through Facebook or OpenID? (Or, as per your reference to James' reasons, Persona?)
What I'm (primarily) talking about is a registration system that complements Django's user system. Registering a user that can log in via Django's built in login functionality as a Django user, with some toggleable features that can be extended by future releases or 3rd party packages. This might not be a 90% use case for all of Django, though I don't know how to measure the number of people that use the various registration tools plus the number that roll their own unnecessarily, but I'd imagine it's useful for a very high percentage of the projects that use Django's user system. On Friday, 1 August 2014 15:30:31 UTC+2, Tim Graham wrote: > > 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/ea15b826-5fe2-45e0-940a-9f4ed3e41a4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
