Re: AbstractUser to get more abstract

2013-09-18 Thread Luke Sneeringer 
Bah, I should have planned my e-mailing better. Sorry for sending a third in 
such rapid succession.

I just did some checking into my assumptions (quoted below) on this. It turns 
out that Django core already does some of what I suggest: in particular, it 
doesn't install the User model if django.contrib.auth is installed but another 
AUTH_USER_MODEL is invoked, based on a Meta option called "swappable" (see 
[here][1] and [here][2]).

Am I misunderstanding? It seems like we are already pretty well down my 
proposed path.

Best Regards,
Luke

  [1]: 
https://github.com/django/django/blob/b2b763448f726ee952743596e9a34fcb154bdb12/django/contrib/auth/models.py#L406-L414
  [2]: 
https://github.com/django/django/blob/master/django/db/models/loading.py#L296


On Sep 18, 2013, at 10:03 PM, Luke Sneeringer  wrote:

> On Wednesday, September 18, 2013 6:39:13 PM UTC-6, Russell Keith-Magee wrote:
> 
> On Thu, Sep 19, 2013 at 3:39 AM, Luke Sneeringer  wrote:
> I added the authtools approach to the wiki for completion, although I believe 
> it to be an inferior approach.
> 
> One thing I dislike is having a separate app (e.g. d.c.auth_email) that has 
> to be installed separately. That feels pretty impure to me. I'm doing a 
> thought exercise about potential solutions, though, and not exactly coming up 
> aces.
> 
> The best solution I can currently think of is to have User and EmailUser 
> which are both models that live in django.contrib.auth. Then, we would have 
> to add code to our model detection that says that *if* a model is a subclass 
> of AbstractBaseUser, include it if and only if it is the AUTH_USER_MODEL.
> 
> I can't decide if that solution is better or worse than the disease. It makes 
> for a much more attractive set of steps to follow for people who want to use 
> it, though -- basically, just set AUTH_USER_MODEL to 'auth.EmailUser', and 
> done.
> 
> 
> My opinion - it's worse than the disease. 
> 
> Option 1 involves a clean auth app that just contains a stub user, and a 
> clean extension app providing an alternative user. You install the extension 
> app, and say you want to use it.
> 
> Option 2 makes a special case of *one particular* extension user, and makes 
> all the internals of models, forms, views, etc embedded inside an if 
> statement.
> 
> 
> I think where I part from you is on the "one particular" aspect of the 
> discussion. I actually see the "option 2" approach as having very clean side 
> effects for some other use cases.
> 
> Allow me to explain:
> There is, as you have pointed out, a lot more to auth than just the User 
> model. There are forms and the like, which you mentioned, but there are also 
> other aspects: the permissions models and functionality, for instance. 
> Subclasses of AbstractBaseUser which also subclass PermissionsMixin still get 
> the permissions things out of the box, and that is a documented use case in 
> the official documentation.
> 
> So, right now (if I understand correctly), if you install the auth app, you 
> get the Group and Permission models (and supporting code, natch), as well as 
> the User model. If you decide to set a different User model using 
> AUTH_USER_MODEL, but you keep auth installed for these other aspects (Group, 
> Permission, etc.) then Django installs an auth_user table that isn't used 
> (note to self: verify this).
> 
> If you set AUTH_USER_MODEL to something other than auth.User, you are making 
> a statement that you do not want the stock model. This is true whether you 
> change it to the upcoming, included "EmailUser" model, or to something else 
> entirely.
> 
> So, I don't think that option 2 "makes a special case of one particular 
> extension user". If anything, I assert it would do the opposite: it actually 
> performs the most expected behavior in all cases. If the plain User model is 
> the AUTH_USER_MODEL and d.c.auth is in INSTALLED APPS, then it is installed. 
> If you choose to use an included-in-core e-mail model and install d.c.auth, 
> you get that model and table instead of the current User model. And, if you 
> use your own, special custom User model, but install auth for the remaining 
> aspects, then you get your custom user model, and not either of the stock 
> ones.
> 
> Basically, my understanding is that you start to get unclean and 
> counter-intuitive behavior when you want to install the auth app for 
> everything other than the User model (and forms, etc.), that this would 
> correct.
> 
> Best Regards,
> Luke
> 
> P. S. To be clear, I am not trying in any way to be argumentative, and I am 
> happy to implement the separate app if that is what the core developers 
> decide on.
> 
> -- 
> 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,

Re: AbstractUser to get more abstract

2013-09-18 Thread Luke Sneeringer 


On Wednesday, September 18, 2013 6:59:17 PM UTC-6, Russell Keith-Magee 
wrote:
>
>
> On Thu, Sep 19, 2013 at 8:37 AM, Aaron Merriam 
>  > wrote:
>
>> Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL 
>> to 'auth.EmailUser', and done".
>>
>> It'd be nice if 'swappable' could accomplish this for us.  Something 
>> along the lines of for any set of swappable models which are swappable for 
>> the same settings value, only load the one that is named by the settings 
>> value.  I am taking some time to read the source surrounding this setting 
>> and model loading to even figure out if this is a possible modification. 
>>  Russel, curious about your thoughts on if this approach would be something 
>> you would sign off on.
>>
>  
> Can't say I'm wild about it. Explicit is better that implicit. 
>

I think I might be missing something salient. How do these solutions vary 
regarding explicit vs. implicit? I guess I don't see why that particular 
line is germane.
 

> If we were going to go down the "single setting" model, I'd rather see it 
> as "you put auth_email in your INSTALLED_APPS, and that automatically sets 
> AUTH_USER_MODEL". However, that requires infrastructure that we don't have 
> at the moment. See my permanent refrain to App Refactor :-) And even then, 
> I'm not necessarily convinced it's the right way to go. I don't see 2 
> explicit settings to be especially onerous, or difficult to explain. One 
> setting installs the app. The other tells Django which model in that app to 
> use. They really are separate concerns.
>

Are they? I guess I see the User model to be used as a setting within 
auth...

Best Regards,
Luke

>  

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

2013-09-18 Thread Luke Sneeringer 


On Wednesday, September 18, 2013 6:39:13 PM UTC-6, Russell Keith-Magee 
wrote:
>
>
> On Thu, Sep 19, 2013 at 3:39 AM, Luke Sneeringer 
>  > wrote:
>
>> I added the authtools approach to the wiki for completion, although I 
>> believe it to be an inferior approach.
>>
>> One thing I dislike is having a separate app (e.g. d.c.auth_email) that 
>> has to be installed separately. That feels pretty impure to me. I'm doing a 
>> thought exercise about potential solutions, though, and not exactly coming 
>> up aces.
>>
>> The best solution I can currently think of is to have User and EmailUser 
>> which are both models that live in django.contrib.auth. Then, we would have 
>> to add code to our model detection that says that *if* a model is a 
>> subclass of AbstractBaseUser, include it if and only if it is the 
>> AUTH_USER_MODEL.
>>
>> I can't decide if that solution is better or worse than the disease. It 
>> makes for a much more attractive set of steps to follow for people who want 
>> to use it, though -- basically, just set AUTH_USER_MODEL to 
>> 'auth.EmailUser', and done.
>>
>>
> My opinion - it's worse than the disease. 
>
> Option 1 involves a clean auth app that just contains a stub user, and a 
> clean extension app providing an alternative user. You install the 
> extension app, and say you want to use it.
>
> Option 2 makes a special case of *one particular* extension user, and 
> makes all the internals of models, forms, views, etc embedded inside an if 
> statement.
>
>
I think where I part from you is on the "one particular" aspect of the 
discussion. I actually see the "option 2" approach as having very clean 
side effects for some other use cases.

Allow me to explain:
There is, as you have pointed out, a lot more to auth than just the User 
model. There are forms and the like, which you mentioned, but there are 
also other aspects: the permissions models and functionality, for instance. 
Subclasses of AbstractBaseUser which also subclass PermissionsMixin still 
get the permissions things out of the box, and that is a documented use 
case in the official documentation.

So, right now (if I understand correctly), if you install the auth app, you 
get the Group and Permission models (and supporting code, natch), as well 
as the User model. If you decide to set a different User model using 
AUTH_USER_MODEL, but you keep auth installed for these other aspects 
(Group, Permission, etc.) then Django installs an auth_user table that 
isn't used (note to self: verify this).

If you set AUTH_USER_MODEL to something other than auth.User, you are 
making a statement that you *do not want* the stock model. This is true 
whether you change it to the upcoming, included "EmailUser" model, or to 
something else entirely.

So, I don't think that option 2 "makes a special case of one particular 
extension user". If anything, I assert it would do the opposite: it 
actually performs the most expected behavior in all cases. If the plain 
User model is the AUTH_USER_MODEL and d.c.auth is in INSTALLED APPS, then 
it is installed. If you choose to use an included-in-core e-mail model and 
install d.c.auth, you get that model and table *instead of* the current 
User model. And, if you use your own, special custom User model, but 
install auth for the remaining aspects, then you get your custom user 
model, and not either of the stock ones.

Basically, my understanding is that you start to get unclean and 
counter-intuitive behavior when you want to install the auth app for 
everything other than the User model (and forms, etc.), that this would 
correct.

Best Regards,
Luke

P. S. To be clear, I am not trying in any way to be argumentative, and I am 
happy to implement the separate app if that is what the core developers 
decide on.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

2013-09-18 Thread Russell Keith-Magee 
On Thu, Sep 19, 2013 at 8:37 AM, Aaron Merriam wrote:

> Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL
> to 'auth.EmailUser', and done".
>
> It'd be nice if 'swappable' could accomplish this for us.  Something along
> the lines of for any set of swappable models which are swappable for the
> same settings value, only load the one that is named by the settings value.
>  I am taking some time to read the source surrounding this setting and
> model loading to even figure out if this is a possible modification.
>  Russel, curious about your thoughts on if this approach would be something
> you would sign off on.
>

Can't say I'm wild about it. Explicit is better that implicit.

Regarding your technical suggestion -- I'm not sure I see how that would
work. auth.User nominates itself as swappable; and then you use
AUTH_USER_MODEL to point myauth.EmailUser as the new User. There's nothing
on EmailUser itself to say "I'm intended for use as a swappable User
model", so there's no way to do the retrospective "don't install me if I'm
not AUTH_USER_MODEL". EmailUser is, in every respect, a "normal" Django
model.

We could add another Meta setting for this, I suppose, but that doesn't fix
the problems with picking the right forms, admin registration, views, and
so on. And we'd be adding that setting for one specific reason - so that
you can have 2 user models in contrib.auth, and only have one installed in
the app cache. The setting wouldn't be any use to anyone else developing a
third-party User model, because they have to do things "the right way" -
install and app, and point the user model at model in the app.

If we were going to go down the "single setting" model, I'd rather see it
as "you put auth_email in your INSTALLED_APPS, and that automatically sets
AUTH_USER_MODEL". However, that requires infrastructure that we don't have
at the moment. See my permanent refrain to App Refactor :-) And even then,
I'm not necessarily convinced it's the right way to go. I don't see 2
explicit settings to be especially onerous, or difficult to explain. One
setting installs the app. The other tells Django which model in that app to
use. They really are separate concerns.

Oh - and Russell, not Russel :-)


> This seems like a good compromise over adding infrastructure for not
> installing certain models.  This would instead create infrastructure to
> declare a certain 'type' of model must be present, but that you may decide
> which one based on a settings value.
>
> This approach feels cleaner to me because we don't want to 'turn off' a
> model, but rather only load a single 'User' model from some set of 'User'
> models.  In the case of 'User', we need at least one 'User' model to be
> loaded, and this enforces that, where as the ability to turn off certain
> models could introduce situations in which someone turns off a model
> without replacing it.
>

Remember - It's not just about models. It's about forms, admin
registrations, views, possibly even URLs.

Yours.
Russ Magee %-)

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

2013-09-18 Thread Russell Keith-Magee 
On Thu, Sep 19, 2013 at 3:39 AM, Luke Sneeringer wrote:

> I added the authtools approach to the wiki for completion, although I
> believe it to be an inferior approach.
>
> One thing I dislike is having a separate app (e.g. d.c.auth_email) that
> has to be installed separately. That feels pretty impure to me. I'm doing a
> thought exercise about potential solutions, though, and not exactly coming
> up aces.
>
> The best solution I can currently think of is to have User and EmailUser
> which are both models that live in django.contrib.auth. Then, we would have
> to add code to our model detection that says that *if* a model is a
> subclass of AbstractBaseUser, include it if and only if it is the
> AUTH_USER_MODEL.
>
> I can't decide if that solution is better or worse than the disease. It
> makes for a much more attractive set of steps to follow for people who want
> to use it, though -- basically, just set AUTH_USER_MODEL to
> 'auth.EmailUser', and done.
>
>
My opinion - it's worse than the disease.

Option 1 involves a clean auth app that just contains a stub user, and a
clean extension app providing an alternative user. You install the
extension app, and say you want to use it.

Option 2 makes a special case of *one particular* extension user, and makes
all the internals of models, forms, views, etc embedded inside an if
statement.

Option 1 strikes me as Django eating it's own dog food. Option 2 is making
the internals of contrib.auth a mess to support one specific use case.
Option 1 lets us provide implicit documentation of "this is how you build a
pluggable User app". Option 2 means we spend our life making sure we're
editing the right code at the right level of indentation.

If it isn't clear by now, I see very little to like in Option 2 :-)

Yours,
Russ Magee %-)

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

2013-09-18 Thread Aaron Merriam 
Luke, I'm +1 on wanting a solution that allows "just set AUTH_USER_MODEL to 
'auth.EmailUser', and done".

It'd be nice if 'swappable' could accomplish this for us.  Something along 
the lines of for any set of swappable models which are swappable for the 
same settings value, only load the one that is named by the settings value. 
 I am taking some time to read the source surrounding this setting and 
model loading to even figure out if this is a possible modification. 
 Russel, curious about your thoughts on if this approach would be something 
you would sign off on.

This seems like a good compromise over adding infrastructure for not 
installing certain models.  This would instead create infrastructure to 
declare a certain 'type' of model must be present, but that you may decide 
which one based on a settings value.

This approach feels cleaner to me because we don't want to 'turn off' a 
model, but rather only load a single 'User' model from some set of 'User' 
models.  In the case of 'User', we need at least one 'User' model to be 
loaded, and this enforces that, where as the ability to turn off certain 
models could introduce situations in which someone turns off a model 
without replacing it.

Aaron Merriam

On Wednesday, September 18, 2013 1:39:16 PM UTC-6, Luke Sneeringer wrote:
>
> I added the authtools approach to the wiki for completion, although I 
> believe it to be an inferior approach.
>
> One thing I dislike is having a separate app (e.g. d.c.auth_email) that 
> has to be installed separately. That feels pretty impure to me. I'm doing a 
> thought exercise about potential solutions, though, and not exactly coming 
> up aces.
>
> The best solution I can currently think of is to have User and EmailUser 
> which are both models that live in django.contrib.auth. Then, we would have 
> to add code to our model detection that says that *if* a model is a 
> subclass of AbstractBaseUser, include it if and only if it is the 
> AUTH_USER_MODEL.
>
> I can't decide if that solution is better or worse than the disease. It 
> makes for a much more attractive set of steps to follow for people who want 
> to use it, though -- basically, just set AUTH_USER_MODEL to 
> 'auth.EmailUser', and done.
>
> Thoughts?
>
> Best Regards,
> Luke Sneeringer
>
> On September 18, 2013 at 7:17:53 AM, Timothy Anderegg (
> timothy@gmail.com ) wrote:
>
> Hi all - I updated Russ's new wiki page to include the work I've done so 
> far: https://code.djangoproject.com/wiki/ContribEmailAuth  Again, the 
> patch I've been working on is here: 
> https://github.com/tanderegg/django/tree/ticket_20824_master  Please let 
> me know if you have any feedback.
>
> The only real other option (that I can see) would be to do something more 
> extensive like django-authtools (
> https://django-authtools.readthedocs.org/en/latest/).  I can write up a 
> description of this approach as well if that would be useful, although I 
> did write up a description of the difference between my code and the two 
> other existing django apps in a post earlier in this thread.
>
> Thanks,
>
> Tim
>
>
> On Wed, Sep 18, 2013 at 1:42 AM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>> On Wed, Sep 18, 2013 at 1:27 PM, Luke Sneeringer 
>> > > wrote:
>>
>>> Russell,
>>> I would *love* to do the work for the email-login analogue you 
>>> describe. I actually proposed just such a thing a few months ago but was 
>>> rebuffed. 
>>>
>>
>> I'm sorry to hear this. Out of interest, did a member of the core team 
>> actually say "no", or was it just a matter of proposing something and not 
>> getting traction? 
>>
>> If it was the latter, it's important to remember that the core team are 
>> all volunteers, and sometimes the spare time of the core team doesn't 
>> necessarily match up with the spare time of volunteers in the wider 
>> community. As a result, well intentioned and desired work sometimes gets 
>> ignored. It's not (necessarily) being ignored because it was bad -- often 
>> it's just "we don't have enough cycles *right now*.
>>   
>>
>>> However, I think this would be extremely useful. Also, I am, in fact, 
>>> looking to get involved with Django development, as I haven't quite 
>>> navigated the hurdles successfully.
>>>
>>> I do have one request, though. Is there a core developer that would be 
>>> willing to "mentor" my work on this, so I can make sure I am writing 
>>> something worthy of acceptance?
>>>
>>  
>> Well, I'm willing to mentor the effort. 
>>
>> Like I've indicated, the first step isn't to write code at all - it's to 
>> get a good summary of the state of play of existing implementations. 
>> Multiple people have already taken a swing at an implementation; before we 
>> commit to one particular codebase, we need to understand what has already 
>> been offered by the community.
>>
>> Yours,
>> Russ Magee %-)
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>>

Re: [GSoC] Composite fields -- another status report

2013-09-18 Thread Michal Petrucha 
Hello everyone,

a lot of time has passed since I last posted a status report here and
I apologize for that.

Composite ForeignKeys were a fairly simple thing to implement with all
the required parts already in place. There is one edge case that I'd
like to handle, where Django would detect attempts to traverse a
composite ForeignKey with select_related while deferring a subset of
its backing fields and raise an error. Other than that, the feature
only needs people to try it out now.

As for the other big thing I've been spending my time on during that
time, I was merging Andrew's migration code into my branch. Certain
parts of migrations need a little bit of tweaking to support virtual
fields. I fixed all regressions caught by the test suite, but there
are a lot of weird corner cases when it comes to virtual fields and
migrations we're already aware of where the code will just fail. This
is an area which will require a lot of polish, so we concentrated on
fixing it for simple (non-composite) ForeignKeys first, the rest can
come later.

I guess this is pretty much it for this year's Sumer of Code. To
recap, I managed to implement the core of the project and a few little
extra features as well. Unfortunately, I didn't manage to write
GenericForeignKey and inspectdb support, which is unfortunate, but a
rather large item popped up which wasn't taken into account in my
proposal, that is the migrations merge.

All in all, I think the project can be considered a success, although
there are still a lot of wrinkles to be ironed out. Of course, I
intend to stick around and get it to a mergeable state and eventually
get around to the features I didn't manage to pull off yet.

The current state of the code is that it doesn't cause any regressions
in the test suite compared to master in either branch. The next thing
to work on (apart from the check I mentioned earlier) is probably
giving more polish to migrations of virtual fields and I'll probably
document how people can write their own custom virtual fields as well.

That's it from me for now.

Michal


signature.asc
Description: Digital signature

Re: Question about new tests

2013-09-18 Thread Justin Holmes 
Florian,

Let me cobble together a demonstration and what I'm talking about; I think
I can more easily illuminate things that way.


On Tue, Sep 17, 2013 at 5:31 PM, Florian Apolloner wrote:

> Hi Justin,
>
> many core developers haven't been at DjangoCon US, so would you mind to
> summarize a few things like: What is the roadmap, how do you plan to tackle
> things; who is involved + whatever else you think would be nice to know for
> someone who more or less heard the first time of this from your mail here.
>
> Thanks & regards,
> Florian
>
>
> On Tuesday, September 17, 2013 7:55:08 PM UTC+2, Justin Holmes wrote:
>>
>> I'm working on the #unsetting project (ie, making all of Django's
>> internals work without having to import the settings global).
>>
>> We have two key areas that now seem to work without running settings:
>> mail and templating.
>>
>> I want to demonstrate these with tests.  Where shall I put these tests?
>>
>> 1) Alongside the respective tests for these features (ie, tests.mail)?
>> 2) As a regression test (ie, also in tests.mail, but demonstrating that
>> the inane errors no longer appear)
>> 3) Alongside the unsetting config?
>>
>> --
>> Justin Holmes
>> Chief Chocobo Breeder, slashRoot
>>
>> slashRoot: Coffee House and Tech Dojo
>> New Paltz, NY 12561
>> 845.633.8330
>>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

2013-09-18 Thread Luke Sneeringer 
I added the authtools approach to the wiki for completion, although I believe 
it to be an inferior approach.

One thing I dislike is having a separate app (e.g. d.c.auth_email) that has to 
be installed separately. That feels pretty impure to me. I'm doing a thought 
exercise about potential solutions, though, and not exactly coming up aces.

The best solution I can currently think of is to have User and EmailUser which 
are both models that live in django.contrib.auth. Then, we would have to add 
code to our model detection that says that *if* a model is a subclass of 
AbstractBaseUser, include it if and only if it is the AUTH_USER_MODEL.

I can't decide if that solution is better or worse than the disease. It makes 
for a much more attractive set of steps to follow for people who want to use 
it, though -- basically, just set AUTH_USER_MODEL to 'auth.EmailUser', and done.

Thoughts?

Best Regards,
Luke Sneeringer
On September 18, 2013 at 7:17:53 AM, Timothy Anderegg 
(timothy.ander...@gmail.com) wrote:

Hi all - I updated Russ's new wiki page to include the work I've done so far: 
https://code.djangoproject.com/wiki/ContribEmailAuth  Again, the patch I've 
been working on is here: 
https://github.com/tanderegg/django/tree/ticket_20824_master  Please let me 
know if you have any feedback.

The only real other option (that I can see) would be to do something more 
extensive like django-authtools 
(https://django-authtools.readthedocs.org/en/latest/).  I can write up a 
description of this approach as well if that would be useful, although I did 
write up a description of the difference between my code and the two other 
existing django apps in a post earlier in this thread.

Thanks,

Tim


On Wed, Sep 18, 2013 at 1:42 AM, Russell Keith-Magee  
wrote:

On Wed, Sep 18, 2013 at 1:27 PM, Luke Sneeringer  wrote:
Russell,
I would love to do the work for the email-login analogue you describe. I 
actually proposed just such a thing a few months ago but was rebuffed.

I'm sorry to hear this. Out of interest, did a member of the core team actually 
say "no", or was it just a matter of proposing something and not getting 
traction? 

If it was the latter, it's important to remember that the core team are all 
volunteers, and sometimes the spare time of the core team doesn't necessarily 
match up with the spare time of volunteers in the wider community. As a result, 
well intentioned and desired work sometimes gets ignored. It's not 
(necessarily) being ignored because it was bad -- often it's just "we don't 
have enough cycles *right now*.
 
However, I think this would be extremely useful. Also, I am, in fact, looking 
to get involved with Django development, as I haven't quite navigated the 
hurdles successfully.

I do have one request, though. Is there a core developer that would be willing 
to "mentor" my work on this, so I can make sure I am writing something worthy 
of acceptance?
 
Well, I'm willing to mentor the effort. 

Like I've indicated, the first step isn't to write code at all - it's to get a 
good summary of the state of play of existing implementations. Multiple people 
have already taken a swing at an implementation; before we commit to one 
particular codebase, we need to understand what has already been offered by the 
community.

Yours,
Russ Magee %-)
--  
You received this message because you are subscribed to a topic in the Google 
Groups "Django developers" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-developers/rb7v9kVAK3I/unsubscribe.
To unsubscribe from this group and all its topics, 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.
For more options, visit https://groups.google.com/groups/opt_out.

--  
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.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

2013-09-18 Thread Florian Apolloner 
Hi,

On Wednesday, September 18, 2013 1:29:25 PM UTC+2, Curtis Maloney wrote:
>
> 1) Can we share "ad-hoc" caches -- that is, ones created by passing more 
> than just the CACHES alias.
>
Imo no, you probably have a good reason if you create ad-hoc ones 

> 2) What to do about django.core.cache.cache ?
>
Has to stay for now, same as django.db.connection
 

> A separate approach is to introduce a new API to provide access to the 
> shared, pre-configured caches, and retain get_cache for the old, ad-hoc, 
> non-shared caches.
>
I think it would be sensible if that API would mimic django.db.connections

Florian.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

2013-09-18 Thread Timothy Anderegg 
Hi all - I updated Russ's new wiki page to include the work I've done so
far: https://code.djangoproject.com/wiki/ContribEmailAuth  Again, the patch
I've been working on is here:
https://github.com/tanderegg/django/tree/ticket_20824_master  Please let me
know if you have any feedback.

The only real other option (that I can see) would be to do something more
extensive like django-authtools (
https://django-authtools.readthedocs.org/en/latest/).  I can write up a
description of this approach as well if that would be useful, although I
did write up a description of the difference between my code and the two
other existing django apps in a post earlier in this thread.

Thanks,

Tim


On Wed, Sep 18, 2013 at 1:42 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Wed, Sep 18, 2013 at 1:27 PM, Luke Sneeringer wrote:
>
>> Russell,
>> I would *love* to do the work for the email-login analogue you describe.
>> I actually proposed just such a thing a few months ago but was rebuffed.
>>
>
> I'm sorry to hear this. Out of interest, did a member of the core team
> actually say "no", or was it just a matter of proposing something and not
> getting traction?
>
> If it was the latter, it's important to remember that the core team are
> all volunteers, and sometimes the spare time of the core team doesn't
> necessarily match up with the spare time of volunteers in the wider
> community. As a result, well intentioned and desired work sometimes gets
> ignored. It's not (necessarily) being ignored because it was bad -- often
> it's just "we don't have enough cycles *right now*.
>
>
>> However, I think this would be extremely useful. Also, I am, in fact,
>> looking to get involved with Django development, as I haven't quite
>> navigated the hurdles successfully.
>>
>> I do have one request, though. Is there a core developer that would be
>> willing to "mentor" my work on this, so I can make sure I am writing
>> something worthy of acceptance?
>>
>
> Well, I'm willing to mentor the effort.
>
> Like I've indicated, the first step isn't to write code at all - it's to
> get a good summary of the state of play of existing implementations.
> Multiple people have already taken a swing at an implementation; before we
> commit to one particular codebase, we need to understand what has already
> been offered by the community.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/rb7v9kVAK3I/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

2013-09-18 Thread Curtis Maloney 
I started working on a CacheManager for dealing with thread local cache
instances, as was suggested on IRC by more than one person.

Firstly, I propose we remove the schema://backend...  syntax for defining
cache configs, as it's no longer even documented [that I could find quickly]

Secondly, have get_cache ask the Cache manager, instead of doing all the
lifting itself.

At this point, I could see two non-trivial things to solve:
1) Can we share "ad-hoc" caches -- that is, ones created by passing more
than just the CACHES alias.
2) What to do about django.core.cache.cache ?

As I was explaining this, something occurred to me: a wrapper object that
remembers the backend/location/params used to create the cache instance,
and deals with accessing the right thread-local instance.

A separate approach is to introduce a new API to provide access to the
shared, pre-configured caches, and retain get_cache for the old, ad-hoc,
non-shared caches.

--
Curtis


On 7 September 2013 22:32, Florian Apolloner  wrote:

> Hi,
>
>
> On Monday, September 2, 2013 6:39:09 AM UTC+2, Curtis Maloney wrote:
>>
>> Whilst it's conceivable  some cache backend will have the smarts to
>> multiplex requests on a single connection, I suspect that's more the
>> exception than the case.
>>
>
> Agreed
>
>
>> Obviously, the default would be one per thread.
>>
>
> This is what the pylibmc backend does already and memcached should do too;
> the db backend is per thread too since it uses Django's db connection. We
> might wanna supply a building block so that not everone has to implement
> their own variant of the threadlocal stuff :)  [Locmem and filebased
> shouldn't cause any issues either way and can stay as they are I think]
>
> Of course, that could be simplified by just always creating a new instance
>> when more than just a name is provided. [or a "force new" keyword is
>> passed].
>>
>
> I wonder how common it is to supply more than just the name to get_cache
> (aside from tests maybe), I am +0 for making get_cache return "cached"
> instances for a single name and construct new ones for the other cases (+ a
> force keyword if someone really wants the old behavior).
>
> Cheers,
> Florian
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.