Re: Pull django-registration into contrib?

[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.


On Saturday, 2 August 2014 19:03:01 UTC+2, Aymeric Augustin wrote:
>
> On 2 août 2014, at 18:08, Tim Graham > 
> 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.
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/46221bee-3cc2-476f-a034-56b0b8099b52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Aymeric Augustin]

On 2 août 2014, at 18:08, Tim Graham  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.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/816E2615-C4BB-4878-B9C2-56519B1867C7%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[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.

On Friday, August 1, 2014 6:13:34 PM UTC-4, James Bennett wrote:
>
> 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.
>  

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/ae72856a-6097-4fdb-8da8-09ed224d35b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[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.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAL13Cg_zyDf7M50KSLeNhR7UtmcTn8uTeYOpNYdbok6POUpMEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[Donald Stufft]

On August 1, 2014 at 10:28:22 AM, Robert Grant (robertlagr...@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

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/etPan.53dc0fe4.6b8b4567.d5d9%40Thor.local.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[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



On Friday, August 1, 2014 9:17:30 AM UTC-7, Collin Anderson wrote:
>
> 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.
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/f5813b1d-529a-45b2-b14a-b4a78cf99757%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[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.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/f5a95a35-9a56-45af-bbf8-1dba75ef91f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull django-registration into contrib?

[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




On Fri, Aug 1, 2014 at 10:28 AM, Robert Grant 
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?)
>
> 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

Re: Pull django-registration into 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.

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

Re: Pull django-registration into contrib?

[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.

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

Re: Pull django-registration into contrib?

[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.


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 
>>  (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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/g

Re: Pull django-registration into contrib?

[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.

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 
>  (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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/d000a15d-0723-41f5-a4b6-5ac18642e7df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/6b097c64-7ab6-4d95-bf19-f7bf3bccad75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.