Pull django-registration into contrib?

[Robert Grant]

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 (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

[Tim Graham]

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.

[Robert Grant]

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.

[Tim Graham]

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.

[Robert Grant]

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.

[Andre Terra]

Hi, Robert,

I just wanted to say that I'm +9000 in favor of your proposal. In fact, I think Django as a whole can benefit from the kind of reasoning behind your argument. Having key strengths is what drives adoption from new users, and that should be any framework's concern. I strongly feel that this sort of "commercial" concern is the only thing that is really lacking in Django as a framework today.

The admin has been touted as one of Django's most prominent features, because it lets you work with data easily and early in the development process. Is it complete? No. Is it perfect? Definitely not. But it's damn good for a significant number of use cases, and that is why it is still part of core. 

For what it's worth, I have used django-registration much more frequently than I have used the admin, and I'm willing to bet that's the case with other users as well. Therefore, the "percentage of use cases" is not a valid argument.

We ought not to confuse is and ought.

Cheers,

AT

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.

[Collin Anderson]

It seems to me, in any case, the first step is to get django-registration actively maintained again. James Bennett is welcoming proposals of people to take over maintenance of the project. Get it working well with custom user models and with python 3. Once django-registration is a thriving app as popular as django-south (about 10x as many people using it), it would make sense to think about the possibility of adding it to contrib.

I think LDAP and oauth (facebook login) support out of the box in django would be great, though I think it's easier said than done, and django-registration doesn't even do it out of the box.

As for me personally. I use the admin in every one of the 18 django websites I maintain, and in the few websites where non-staff users login to the website, including this line in urls.py goes a long way for me:

    url(r'^accounts/', include('django.contrib.auth.urls')),

If email-verification is required, I re-use the password reset code to handle the tokens.

[Daniel Greenfeld]

What no one is discussing here is is that django-registration is just one out of several popular authentication backends that match it for use and great exceed it's functionality. They include:

* django-allauth

* django-userena

* python-social-auth (nee django-social-auth)

These three projects are extremely well maintained (huge communities of supporters), support dozens of OAuth implementations, and are the modern cornerstone of current Django registration. Bugs are fixed quickly, updates for OAuth providers come frequently, and **just plain work without forking**.

django-allauth in particular not only easily mirrors django-registration core functiomality, it has a safer logout mechanism.

Why do I bring this up? Well, if Django is going to have a built-in registration system, then I think it should benefit from having more eyes on the problem. While James Bennett is an awesome coder whose work has been a foundation of my own, his solitary effort (https://www.djangopackages.com/packages/p/django-registration/ shows only one committer) simply doesn't compare to the legions of people who have contributed to these other packages. Therefore, I submit that if a registration package will be brought into django.contrib, it should be one of these alternatives.

That said, I don't like the idea of adding more functionality to Django, even within django.contrib. IMO, a better alternative would be to suggest registration packages in the documentation of django.contrib.auth.

--Daniel Greenfeld

[Donald Stufft]

On August 1, 2014 at 10:28:22 AM, Robert Grant (robert...@gmail.com) wrote:
> 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?)
> 

I think the difference between django-registration and South is that
there is a benefit to blessing a singular migrations framework as
the one true way of doing it. Namely that is interoperability.

The same can be said for django.contrib.auth as well. As long as any
system which uses users ties into that, then they’ll all interopt
with each other. The same cannot be said for the registration system
since generally most pieces of a site do not interact with the
registration system, especially not at the level as they would for
the generic concept of users or database migrations.

--
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

[James Bennett]

Speaking for myself, I am still willing to hand over the reins of django-registration to someone who's genuinely motivated to try to solve the issues surrounding things like custom User support, etc., though I still do believe that's just a bridge too far for what was meant to be a simple app.

I've been toying with the idea of splitting off a "django-simple-registration" from an earlier version of the codebase, building around 1.6/1.7+ idioms and just ignoring a lot of the things Django allows people to do in favor of handling a few basic common workflows, and let stuff like allauth be the all-singing, all-dancing, everything-and-the-kitchen-sink user apps.

[Tim Graham]

On a related note, djangoproject.com depends on django-registration so we need to update it for 1.7 compatibility or remove the dependency.

[Aymeric Augustin]

On 2 août 2014, at 18:08, Tim Graham <timog...@gmail.com> wrote:

On a related note, djangoproject.com depends on django-registration so we need to update it for 1.7 compatibility or remove the dependency.

Then our most reasonable option is to fork it under django/django-registration, isn’t it?

Oh, the irony :->

-- 

Aymeric.

[Robert Grant]

If you do want to update it then there's a version I'm using with Django 1.6 and Python 3.4 here: https://github.com/macropin/django-registration. Might be a good start.