Re: #3011 - Custom User Models -- Call for final review

2012-09-18 Thread Donald Stufft
On Tuesday, September 18, 2012 at 10:34 PM, Ben Slavin wrote: > Those apps that require (or choose to offer) a deeper stack of version > support can choose to do so, but the pragmatism of making the common case > easy (and removing the need for cross-project duplication) seems to justify > the

Re: #3011 - Custom User Models -- Call for final review

2012-09-18 Thread Ben Slavin
On Tuesday, September 18, 2012 9:34:38 PM UTC-4, dstufft wrote: > > On Tuesday, September 18, 2012 at 9:13 PM, Ben Slavin wrote: > > Lastly, I haven't seen a path to easily allow third-party apps to > gracefully support both The Old Way and The New Way (1.4 and 1.5). It feels > a bit wrong, but

Re: #3011 - Custom User Models -- Call for final review

2012-09-18 Thread Ben Slavin
> > If your project specifies a custom user, you should get validation > warnings saying that there are foreign keys to a swapped model (and > indicate which foreign keys are affected). > Indeed I did. This was greatly appreciated. > This does means that there is a "1.5 compatible" barrier

Re: #3011 - Custom User Models -- Call for final review

2012-09-18 Thread Russell Keith-Magee
On Wed, Sep 19, 2012 at 9:13 AM, Ben Slavin wrote: > Hi Russ, > > First, let me apologize for being a bit late to the party on this. If > there's been prior discussion of any of the points below kindly tell me to > get stuffed and so shall I do. You asked for it… :-)

Re: #3011 - Custom User Models -- Call for final review

2012-09-18 Thread Donald Stufft
On Tuesday, September 18, 2012 at 9:13 PM, Ben Slavin wrote: > Lastly, I haven't seen a path to easily allow third-party apps to gracefully > support both The Old Way and The New Way (1.4 and 1.5). It feels a bit wrong, > but should we be considering the addition of get_user_model and >

Re: #3011 - Custom User Models -- Call for final review

2012-09-18 Thread Ben Slavin
Hi Russ, First, let me apologize for being a bit late to the party on this. If there's been prior discussion of any of the points below kindly tell me to get stuffed and so shall I do. Our team has been working with the t3011 branch today. We ran into some trouble running tests locally. The

Re: Results of testing votizen's py2.6/7 codebase against django master (319e1355190)

2012-09-18 Thread Jeremy Dunck
On Tue, Sep 18, 2012 at 11:23 AM, Jeremy Dunck wrote: ... > And the last one, I hesitate to raise because it's likely to be > specific to my machine, but... our (django-nose-based) test runner > hangs after completing the suite but before tearing down. Using > dtruss I can see

Results of testing votizen's py2.6/7 codebase against django master (319e1355190)

2012-09-18 Thread Jeremy Dunck
In response to the call to test py2.x on django's current master, I ran the test suite for Votizen. Our codebase is currently running with django 1.4.x. Our codebase is ~100kloc, ~32kloc of which is tests. We use abstract model inheritance a good bit, but no concrete inheritance. No i18n or

Re: Schema Alteration - Review needed!

2012-09-18 Thread Andrew Godwin
An update from discussions with Alex and Anssi - I'm going to modify things a little so we don't have a Borg-pattern AppCache (i.e. you can instantiate it multiple times and get different caches), which should solve most of the problems currently caused by app cache state fiddling. Should take a