Re: [GSoC 2012] Improved error reporting

[Russell Keith-Magee]

On 16/03/2012, at 2:07 AM, Boris Bobrov wrote:

> В сообщении от Thursday 15 of March 2012 11:07:03 Russell написал:
> 
>> Essentially, we're going to be looking for evidence that you understand the
>> scope of the problem you're proposing to solve. Generic statements like
>> "I'm going to fix the errors in X" aren't especially convincing by
>> themselves.
>> 
>> To put it another way: Our selection process is essentially guided by
>> looking at the proposals, and determining what we (as a project) are going
>> to get out of the project at the end of the GSoC. A generic plan that says
>> "I'm going to spend 12 weeks fixing error messages in Django" doesn't
>> really let us know what the end product will be. Will you fix 1 error? 10?
>> 100? Will they all be in contrib? django.core?
>> 
>> We also need to be convinced that you appear to understand the complexity
>> (or lack of complexity) of the problem you're proposing to fix, and that
>> you have a plan that will enable you to deliver on what you're promising.
>> A plan that just says "I'm going to fix these 10 problems" without
>> providing any details isn't very helpful either. Yes, it would be good to
>> have 10 less problems -- but how do we know that the 10 problems can
>> actually be fixed in 12 weeks? Or, at the other end of the scale -- how do
>> we know that you're not going to be finished in a week?
>> 
>> What we really need is a list of the areas you're going to look at, and
>> some sort of analysis of the source of the problems in those areas --
>> e.g., is it just a matter of the error messages being unhelpful, or is
>> there something fundamental that needs to be fixed (e.g., internally
>> generated exceptions being re-raised in unhelpful ways, or exceptions
>> being raised by a side effect, rather than the real problem).
>> 
>> You don't have to go to the level of enumerating every single error message
>> you will fix (although that would certainly be nice!), but we will be
>> looking for a rigorous analysis. This will require some research and
>> elaboration on your part.
>> 
>> A good rule of thumb: Can you produce a convincing timeline for a 12 week
>> project? If your project plan is filled with "3 weeks: Fix errors in
>> admin", then you haven't provided us with any evidence that you understand
>> the scope of the problem. If you can get to 1 week granularity, you're
>> starting to be convincing. Granularity at the level of days would be
>> excellent.
> 
> Thanks, got it.
> What's the deadline for that plan submission? Do I have to send it before the 
> applications acceptance date, in my application or during the Interim Period 
> (April 6-20)?

The only deadline is the end-of-submissions deadline, on Friday 6 April. (The 
April 6-20 period is where we rank and select proposals) The formal submission 
period starts on 26 March, but we don't enforce that at a project level -- if 
you want to get started early, please do.

> Will it be a one-time submission or some (little) discussion will be held 
> about it with possibility to fix and change some parts of that plan?

We encourage students to send their draft proposals to django-developers so we 
can give them feedback. This gives us an opportunity to evaluate how you work 
with the community, and gives you the opportunity to revise and improve your 
proposals. Obviously, this isn't a completely limitless resource -- you can't 
send dozens of drafts and expect to get feedback every time -- but it would be 
unusual for a project to *not* go through at least 2 or 3 revisions. 

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Carl Meyer]

Hi Daniel,

On 03/15/2012 11:48 AM, Daniel Sokolowski wrote:
> The issue here is that django auth is limited, and restrictive and needs
> hacks to make it use emails as usernames, we can agree on that yes? 

Certainly.

> We
> can also agree that contrib.auth2 with LFK is a complex undertaking far
> into the future?. 

It is not a simple undertaking. How far into the future it is depends
entirely on whether someone who wants to see it happen takes it upon
themselves to make it happen.

> Can we also agree that the 30 character limitation on
> the username ought to be increased?

I am not sure whether this should happen as a separate step or not. In
an ideal world, we would have a longer username field. In the real
world, we have to balance the benefit against the cost, and requiring a
schema migration from practically every Django installation on the
planet would IMO be the most significant backwards-incompatible change
Django has ever shipped, at least since Django 1.0. It is not at all
clear to me that the status quo, bad as it is, is worse than this cure.

The cost would be mitigated somewhat if we had schema migrations in
core, which would make the upgrade instructions much simpler and more
foolproof.

The cost would be reduced even more if we simply shipped this as part of
a larger customizable-auth change (which will probably require at least
a deprecation path itself).

So, in my opinion, your energies would be more productively directed
towards helping make one of those latter two things happen. But feel
free to work on a proposal to simply change the field length. If you can
provide a patch with a really compelling backwards-compatibility story,
my mind is certainly open to change.

Carl



signature.asc
Description: OpenPGP digital signature

Model.save and Model.full_clean

[Donald Stufft]

I'm working up a documentation patch to make this spelled out more explicitly
but I wonder if there isn't more that should be done.

Currently ``Model.full_clean`` is not called automatically when saving a model.
This is not a big deal when manually constructing your models as you can
just do:

m = MyModel(field=foo)
m.full_clean()
m.save()

However there is no easy way to get a similar behavior when using 
``MyModel.objects.create``
or ``MyModel.objects.get_or_create``.

The documentation currently mentions that get_or_create is useful in data 
import scripts, but
also mentions using it in views. My patches will try to make it more explicit 
that it's unsafe
to assume that the constraints in the field (e.g. URLField) will be enforced 
but I wonder if
maybe it would make sense to either make running ``full_clean`` the default or 
provide a way
for people to specify that it should be ran. It appears that it's not run by 
default due to
backwards compatibility: https://code.djangoproject.com/changeset/12103 .

Currently I would assume that both because of the lack of warning in the 
documentation, and
because it isn't obvious behavior (e.g. an URLField that accepts unsafe input, 
such as
``javascript:alert("xss");``),  that more than one Django powered site is 
vulnerable to attacks
such as an XSS where they are using ``create`` or ``get_or_create`` manually 
without passing
through a form. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Clay McClure]

On Thu, Mar 15, 2012 at 2:48 PM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:


> The issue here is that django auth is limited, and restrictive and needs
> hacks to make it use emails as usernames, we can agree on that yes?


I agree with this point.


> We can also agree that contrib.auth2 with LFK is a complex undertaking far
> into the future?


I agree that LFK isn't a simple undertaking, and doesn't solve all the
auth.User problems, anyway.


> Can we also agree that the 30 character limitation on the username ought
> to be increased?


I don't agree that changing the length of the username field is the general
solution to the problem of email authentication. First, there's the issue
of backwards compatibility: as Carl pointed out, you can't just change the
size of the field without requiring a schema migration in every existing
django installation, and that's very painful. Second, there's the issue
that if you're storing emails in your username field, you've got a
redundant email field floating around.

With pluggable auth apps, you could make a User model with a longer
username field, if you decide that's the best solution for your app, and if
you're comfortable with the schema migration. I might elect to use a
different User model that foregoes the username field altogether. With
pluggable auth apps, the choice is mine—and yours. :)

Cheers,

Clay

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Daniel Sokolowski]

Ok to recap,

The issue here is that django auth is limited, and restrictive and needs 
hacks to make it use emails as usernames, we can agree on that yes? We can 
also agree that contrib.auth2 with LFK is a complex undertaking far into the 
future?. Can we also agree that the 30 character limitation on the username 
ought to be increased?


-Original Message- 
From: Luke Sneeringer

Sent: Thursday, March 15, 2012 2:11 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

On March 15, 2012, at 12:23 , Daniel Sokolowski wrote:

Carl, I sincerely appreciate your feedback, however again it seems no 
answers are given except more questions and considerations to consider. 
Why is it so unreasonable that we expect the end developer to be able to 
manually adjust their schemas, it's part of an upgrade process and it's 
been done in the past labelled backwards incompatible changes due to bugs 
or security, perhaps 30 character limitation ought to be considered a 
design bug - tomorrow I'll do an R day and see the feasibility of a 
solution.




I don't think Carl's point was to provide answers; his point was to explain 
why the proposal isn't a very good one. He doesn't have to propose an 
alternative to establish that a proposal doesn't work.


Most of Django's backwards incompatible changes are corner cases that most 
end developers never actually encounter. The only exception I can think of 
to this is the CSRF changes to AJAX requests in Django 1.3. This change, on 
the other hand, would affect basically every single Django installation; 
this is much more widespread than past Django releases.


Regards,
Luke



-Original Message- From: Carl Meyer
Sent: Thursday, March 15, 2012 12:49 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

--
You received this message because you are subscribed to the Google Groups 
"Django developers" group.

To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




--
You received this message because you are subscribed to the Google Groups 
"Django developers" group.

To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Luke Sneeringer]

On March 15, 2012, at 12:23 , Daniel Sokolowski wrote:

> Carl, I sincerely appreciate your feedback, however again it seems no answers 
> are given except more questions and considerations to consider. Why is it so 
> unreasonable that we expect the end developer to be able to manually adjust 
> their schemas, it's part of an upgrade process and it's been done in the past 
> labelled backwards incompatible changes due to bugs or security, perhaps 30 
> character limitation ought to be considered a design bug - tomorrow I'll do 
> an R day and see the feasibility of a solution.
> 

I don't think Carl's point was to provide answers; his point was to explain why 
the proposal isn't a very good one. He doesn't have to propose an alternative 
to establish that a proposal doesn't work.

Most of Django's backwards incompatible changes are corner cases that most end 
developers never actually encounter. The only exception I can think of to this 
is the CSRF changes to AJAX requests in Django 1.3. This change, on the other 
hand, would affect basically every single Django installation; this is much 
more widespread than past Django releases.

Regards,
Luke


> -Original Message- From: Carl Meyer
> Sent: Thursday, March 15, 2012 12:49 PM
> To: django-developers@googlegroups.com
> Subject: Re: authentication by email
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [GSoC 2012] Improved error reporting

[Boris Bobrov]

В сообщении от Thursday 15 of March 2012 11:07:03 Russell написал:

> Essentially, we're going to be looking for evidence that you understand the
> scope of the problem you're proposing to solve. Generic statements like
> "I'm going to fix the errors in X" aren't especially convincing by
> themselves.
> 
> To put it another way: Our selection process is essentially guided by
> looking at the proposals, and determining what we (as a project) are going
> to get out of the project at the end of the GSoC. A generic plan that says
> "I'm going to spend 12 weeks fixing error messages in Django" doesn't
> really let us know what the end product will be. Will you fix 1 error? 10?
> 100? Will they all be in contrib? django.core?
> 
> We also need to be convinced that you appear to understand the complexity
> (or lack of complexity) of the problem you're proposing to fix, and that
> you have a plan that will enable you to deliver on what you're promising.
> A plan that just says "I'm going to fix these 10 problems" without
> providing any details isn't very helpful either. Yes, it would be good to
> have 10 less problems -- but how do we know that the 10 problems can
> actually be fixed in 12 weeks? Or, at the other end of the scale -- how do
> we know that you're not going to be finished in a week?
> 
> What we really need is a list of the areas you're going to look at, and
> some sort of analysis of the source of the problems in those areas --
> e.g., is it just a matter of the error messages being unhelpful, or is
> there something fundamental that needs to be fixed (e.g., internally
> generated exceptions being re-raised in unhelpful ways, or exceptions
> being raised by a side effect, rather than the real problem).
> 
> You don't have to go to the level of enumerating every single error message
> you will fix (although that would certainly be nice!), but we will be
> looking for a rigorous analysis. This will require some research and
> elaboration on your part.
> 
> A good rule of thumb: Can you produce a convincing timeline for a 12 week
> project? If your project plan is filled with "3 weeks: Fix errors in
> admin", then you haven't provided us with any evidence that you understand
> the scope of the problem. If you can get to 1 week granularity, you're
> starting to be convincing. Granularity at the level of days would be
> excellent.

Thanks, got it.
What's the deadline for that plan submission? Do I have to send it before the 
applications acceptance date, in my application or during the Interim Period 
(April 6-20)?
Will it be a one-time submission or some (little) discussion will be held 
about it with possibility to fix and change some parts of that plan?

-- 
WBR, 
Boris. 


signature.asc
Description: This is a digitally signed message part.

Re: authentication by email

[Daniel Sokolowski]

Carl, I sincerely appreciate your feedback, however again it seems no 
answers are given except more questions and considerations to consider. Why 
is it so unreasonable that we expect the end developer to be able to 
manually adjust their schemas, it's part of an upgrade process and it's been 
done in the past labelled backwards incompatible changes due to bugs or 
security, perhaps 30 character limitation ought to be considered a design 
bug - tomorrow I'll do an R day and see the feasibility of a solution.


-Original Message- 
From: Carl Meyer

Sent: Thursday, March 15, 2012 12:49 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[colinta]

before we lay this discussion to rest, I would like the dissenters to
feast your eyes on this great new feature that *you have approved*:

http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger

and don't forget, this *is coming soon* (at least, I hope it is)

https://code.djangoproject.com/wiki/SummerOfCode2012

These tags are a great idea.  Moving HTML-related code into the
template *gasp* and out of the forms, so that designers can do their
thing, and it will make it easier to write javascript: adding classes
and setting ids, which is inherently *template* (aka DOM) related
stuff.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [1.4] SECRET_KEY deprecation is confusing...

[Carl Meyer]

On 03/15/2012 07:52 AM, Nick Pope wrote:
> There is a problem in 1.4rc2 where a missing SECRET_KEY causes Django to
> refuse to start.
> 
> According to the current version of the release notes on the
> website: *In Django 1.4, starting Django with an empty SECRET_KEY will
> raise a DeprecationWarning. In Django 1.5, it will raise an exception
> and Django will refuse to start.*
> *
> *
> This doesn't make sense...  It currently raises DeprecationWarning which
> is an exception which causes Django to fail to start.  To trigger a
> deprecation warning while allowing execution to continue you need to use
> warnings.warn().
> 
> As things stand you are essentially implementing the behaviour for both
> 1.4 *and* 1.5!

Indeed; thanks for the report. I've now fixed it to use warnings.warn,
as it should have originally.

Carl



signature.asc
Description: OpenPGP digital signature

Re: authentication by email

[Carl Meyer]

On 03/15/2012 09:41 AM, Daniel Sokolowski wrote:
> Yes it clearly would, however I see two possible solutions to make it
> more friendly:
> 
> 1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it -
> I mean the actual commands to execute.
> 2. Catch the DB error and throw a form validation warning for those that
> didn't.

Catching the database error won't work - some databases won't raise an
error, they'll just silently truncate the value, potentially leading to
all sorts of nasty data corruption problems and confusing bugs down the
road.

Carl



signature.asc
Description: OpenPGP digital signature

Re: authentication by email

[Carl Meyer]

Hi Daniel,

On 03/15/2012 09:24 AM, Daniel Sokolowski wrote:
> Why can we not just increase the length limit on the username field?,
> Why can't we just throw a validation error if data entered is to long
> and the schema has not been updated? I think the answer yes we can and
> easily.

I don't mean to pick on you specifically, but to me this is an excellent
example of a casual assertion of something we can "easily" do that
doesn't hold up under real examination (for instance, if you tried to
write the patch to actually do it).

How do you propose to "throw a validation error" if "the schema has not
been updated"? How do we know whether it's been updated? Are you
proposing that Django should introspect the users database table every
time it starts up in order to check the length of the username field?
Where would you put this introspection check? Have you considered the
effects this would have on every user of contrib.auth (both those who do
and don't run the schema migration)? And the effect on Django
development (needing to run the tests with both an "old" and "new" table
to ensure that the backwards-compatibility handling is tested?)

Carl



signature.asc
Description: OpenPGP digital signature

Re: authentication by email

[Daniel Sokolowski]

That would be a workable compromise, yes?

-Original Message- 
From: Daniel Sokolowski

Sent: Thursday, March 15, 2012 12:41 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

Yes it clearly would, however I see two possible solutions to make it more
friendly:

1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it - I
mean the actual commands to execute.
2. Catch the DB error and throw a form validation warning for those that
didn't.

-Original Message- 
From: Luke Sneeringer

Sent: Thursday, March 15, 2012 12:28 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email



On March 15, 2012, at 11:24 , Daniel Sokolowski wrote:

Tom makes a good point, but you can already store emails in the username, 
they are just limited to 30 characters or fewer. Lift this length 
restriction and I will be able to do everything I need without having to 
wait for contrib.auth2. In the 'I use django to make a living' world the 
solution doesn't have to be perfect just good enough. The talk of lazy 
foreign keys just so we can create contrib.auth2 just rubs me the wrong 
way, adds additional complexity, and I see no benefit of it over a 
UserProfile model or with model inheritance.


And Django developer ought to be familiar how to do a schema migration for 
this simple change, and if they fail to know instructions can be provided 
in the release notes; there is NO need to have progress being stalled 
because there is no built automated schema migration.


Why can we not just increase the length limit on the username field?, Why 
can't we just throw a validation error if data entered is to long and the 
schema has not been updated? I think the answer yes we can and easily.


Wouldn't increasing the length of the username field *also* incur a schema
migration? After all, anyone who has spun up a Django site previous to the
change would have a CHARACTER VARYING(30) (or a VARCHAR(30) or whatever the
appropriate database-specific type is) in their database. So, we'd have a
situation where Django would accept a 40 character email address, but then
the database would truncate it or error out.

The argument that Django developers ought to know how to do the schema
migrations themselves seems poor to me. I expect some don't, and it's
certainly a bigger backwards incompatible change than the Django development
community has traditionally been comfortable with.

Regards,
Luke



-Original Message- From: Tom Evans
Sent: Friday, March 09, 2012 11:46 AM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant  wrote:

On 09/03/12 14:49, Tom Evans wrote:

Yes, since no one needs it. Okay no one isn't true, but no one (for 
true
this time) who needed it stepped up and said "I'll implement it and see 
that

it ends up in trunk"



I'm sorry, that completely mis-characterises the situation. Lots of
people want this, but every single time this has been brought up since
I started using django (1.0), a core dev or BFDL has explicitly ruled
it out, saying "we cannot do this, requires schema migration, we'll
look at it for the next version".


This is not true. There have been times when we have said we cannot
consider it right now, and that a solid proposal should be brought up at
the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the
core developers can look at it.

And every time, the proposal has either been missing or simply not been
adequate - for example, the GSoC 2010 and 2011 proposals regarding this.
Russell gave detailed feedback on why these solutions were not adequate
[1], and at other times has provided feedback on possible strategies
[2]. And the people who went away to work on the problem have gone
silent or admitted defeat. One presumes they fixed their immediate
problem in a way that would not be a general solution, and moved on, and
that is perfectly understandable. A adequate solution to this is very
hard, and probably requires solving several other big problems first
(like at least one of lazy foreign keys/virtual models/database 
migrations).


It isn't, however, impossible. Our definition of 'need' is that someone
is sufficiently motivated to overcome the obstacles, and contribute a
solution that works for other people as well as themselves.

Regards,

Luke


[1] http://goo.gl/swTpr

[2] http://goo.gl/7p1JN



I disagree. There are small problems with the User model that have not
been fixed. Every proposal you've listed does not address these
issues, but instead looks to find ways of replacing the base user
object, which is a complex and difficult project.

There is a reason why these are the proposals. Every time someone
proposes fixing these minor bugs, the cry from on high is that
instead, d.c.auth will be overhauled to allow for more customization
by the project, immediately increasing the scope and complexity. But
this 

Re: authentication by email

[Daniel Sokolowski]

Yes it clearly would, however I see two possible solutions to make it more 
friendly:


1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it - I 
mean the actual commands to execute.
2. Catch the DB error and throw a form validation warning for those that 
didn't.


-Original Message- 
From: Luke Sneeringer

Sent: Thursday, March 15, 2012 12:28 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email



On March 15, 2012, at 11:24 , Daniel Sokolowski wrote:

Tom makes a good point, but you can already store emails in the username, 
they are just limited to 30 characters or fewer. Lift this length 
restriction and I will be able to do everything I need without having to 
wait for contrib.auth2. In the 'I use django to make a living' world the 
solution doesn't have to be perfect just good enough. The talk of lazy 
foreign keys just so we can create contrib.auth2 just rubs me the wrong 
way, adds additional complexity, and I see no benefit of it over a 
UserProfile model or with model inheritance.


And Django developer ought to be familiar how to do a schema migration for 
this simple change, and if they fail to know instructions can be provided 
in the release notes; there is NO need to have progress being stalled 
because there is no built automated schema migration.


Why can we not just increase the length limit on the username field?, Why 
can't we just throw a validation error if data entered is to long and the 
schema has not been updated? I think the answer yes we can and easily.


Wouldn't increasing the length of the username field *also* incur a schema 
migration? After all, anyone who has spun up a Django site previous to the 
change would have a CHARACTER VARYING(30) (or a VARCHAR(30) or whatever the 
appropriate database-specific type is) in their database. So, we'd have a 
situation where Django would accept a 40 character email address, but then 
the database would truncate it or error out.


The argument that Django developers ought to know how to do the schema 
migrations themselves seems poor to me. I expect some don't, and it's 
certainly a bigger backwards incompatible change than the Django development 
community has traditionally been comfortable with.


Regards,
Luke



-Original Message- From: Tom Evans
Sent: Friday, March 09, 2012 11:46 AM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant  wrote:

On 09/03/12 14:49, Tom Evans wrote:

Yes, since no one needs it. Okay no one isn't true, but no one (for 
true
this time) who needed it stepped up and said "I'll implement it and see 
that

it ends up in trunk"



I'm sorry, that completely mis-characterises the situation. Lots of
people want this, but every single time this has been brought up since
I started using django (1.0), a core dev or BFDL has explicitly ruled
it out, saying "we cannot do this, requires schema migration, we'll
look at it for the next version".


This is not true. There have been times when we have said we cannot
consider it right now, and that a solid proposal should be brought up at
the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the
core developers can look at it.

And every time, the proposal has either been missing or simply not been
adequate - for example, the GSoC 2010 and 2011 proposals regarding this.
Russell gave detailed feedback on why these solutions were not adequate
[1], and at other times has provided feedback on possible strategies
[2]. And the people who went away to work on the problem have gone
silent or admitted defeat. One presumes they fixed their immediate
problem in a way that would not be a general solution, and moved on, and
that is perfectly understandable. A adequate solution to this is very
hard, and probably requires solving several other big problems first
(like at least one of lazy foreign keys/virtual models/database 
migrations).


It isn't, however, impossible. Our definition of 'need' is that someone
is sufficiently motivated to overcome the obstacles, and contribute a
solution that works for other people as well as themselves.

Regards,

Luke


[1] http://goo.gl/swTpr

[2] http://goo.gl/7p1JN



I disagree. There are small problems with the User model that have not
been fixed. Every proposal you've listed does not address these
issues, but instead looks to find ways of replacing the base user
object, which is a complex and difficult project.

There is a reason why these are the proposals. Every time someone
proposes fixing these minor bugs, the cry from on high is that
instead, d.c.auth will be overhauled to allow for more customization
by the project, immediately increasing the scope and complexity. But
this fabled d.c.auth2 never appears.

In fact, your reply alludes to this. We're talking about why a field
is too short to contain valid values, and you suggest that the
solution inevitably will involve "lazy 

Re: authentication by email

[Luke Sneeringer]

On March 15, 2012, at 11:24 , Daniel Sokolowski wrote:

> Tom makes a good point, but you can already store emails in the username, 
> they are just limited to 30 characters or fewer. Lift this length restriction 
> and I will be able to do everything I need without having to wait for 
> contrib.auth2. In the 'I use django to make a living' world the solution 
> doesn't have to be perfect just good enough. The talk of lazy foreign keys 
> just so we can create contrib.auth2 just rubs me the wrong way, adds 
> additional complexity, and I see no benefit of it over a UserProfile model or 
> with model inheritance.
> 
> And Django developer ought to be familiar how to do a schema migration for 
> this simple change, and if they fail to know instructions can be provided in 
> the release notes; there is NO need to have progress being stalled because 
> there is no built automated schema migration.
> 
> Why can we not just increase the length limit on the username field?, Why 
> can't we just throw a validation error if data entered is to long and the 
> schema has not been updated? I think the answer yes we can and easily.

Wouldn't increasing the length of the username field *also* incur a schema 
migration? After all, anyone who has spun up a Django site previous to the 
change would have a CHARACTER VARYING(30) (or a VARCHAR(30) or whatever the 
appropriate database-specific type is) in their database. So, we'd have a 
situation where Django would accept a 40 character email address, but then the 
database would truncate it or error out.

The argument that Django developers ought to know how to do the schema 
migrations themselves seems poor to me. I expect some don't, and it's certainly 
a bigger backwards incompatible change than the Django development community 
has traditionally been comfortable with.

Regards,
Luke

> 
> -Original Message- From: Tom Evans
> Sent: Friday, March 09, 2012 11:46 AM
> To: django-developers@googlegroups.com
> Subject: Re: authentication by email
> 
> On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant  wrote:
>> On 09/03/12 14:49, Tom Evans wrote:
>> 
 Yes, since no one needs it. Okay no one isn't true, but no one (for true
 this time) who needed it stepped up and said "I'll implement it and see 
 that
 it ends up in trunk"
 
>>> 
>>> I'm sorry, that completely mis-characterises the situation. Lots of
>>> people want this, but every single time this has been brought up since
>>> I started using django (1.0), a core dev or BFDL has explicitly ruled
>>> it out, saying "we cannot do this, requires schema migration, we'll
>>> look at it for the next version".
>> 
>> This is not true. There have been times when we have said we cannot
>> consider it right now, and that a solid proposal should be brought up at
>> the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the
>> core developers can look at it.
>> 
>> And every time, the proposal has either been missing or simply not been
>> adequate - for example, the GSoC 2010 and 2011 proposals regarding this.
>> Russell gave detailed feedback on why these solutions were not adequate
>> [1], and at other times has provided feedback on possible strategies
>> [2]. And the people who went away to work on the problem have gone
>> silent or admitted defeat. One presumes they fixed their immediate
>> problem in a way that would not be a general solution, and moved on, and
>> that is perfectly understandable. A adequate solution to this is very
>> hard, and probably requires solving several other big problems first
>> (like at least one of lazy foreign keys/virtual models/database migrations).
>> 
>> It isn't, however, impossible. Our definition of 'need' is that someone
>> is sufficiently motivated to overcome the obstacles, and contribute a
>> solution that works for other people as well as themselves.
>> 
>> Regards,
>> 
>> Luke
>> 
>> 
>> [1] http://goo.gl/swTpr
>> 
>> [2] http://goo.gl/7p1JN
>> 
> 
> I disagree. There are small problems with the User model that have not
> been fixed. Every proposal you've listed does not address these
> issues, but instead looks to find ways of replacing the base user
> object, which is a complex and difficult project.
> 
> There is a reason why these are the proposals. Every time someone
> proposes fixing these minor bugs, the cry from on high is that
> instead, d.c.auth will be overhauled to allow for more customization
> by the project, immediately increasing the scope and complexity. But
> this fabled d.c.auth2 never appears.
> 
> In fact, your reply alludes to this. We're talking about why a field
> is too short to contain valid values, and you suggest that the
> solution inevitably will involve "lazy foreign keys/virtual
> models/database migrations" - it's changing one line, and adding a
> comment to relnotes!
> 
> We may have to agree to disagree on how easy some of these things are to fix.
> 
> Lets look at one isolated aspect. The User 

Re: authentication by email

[Daniel Sokolowski]

Tom makes a good point, but you can already store emails in the username, 
they are just limited to 30 characters or fewer. Lift this length 
restriction and I will be able to do everything I need without having to 
wait for contrib.auth2. In the 'I use django to make a living' world the 
solution doesn't have to be perfect just good enough. The talk of lazy 
foreign keys just so we can create contrib.auth2 just rubs me the wrong way, 
adds additional complexity, and I see no benefit of it over a UserProfile 
model or with model inheritance.


And Django developer ought to be familiar how to do a schema migration for 
this simple change, and if they fail to know instructions can be provided in 
the release notes; there is NO need to have progress being stalled because 
there is no built automated schema migration.


Why can we not just increase the length limit on the username field?, Why 
can't we just throw a validation error if data entered is to long and the 
schema has not been updated? I think the answer yes we can and easily.



-Original Message- 
From: Tom Evans

Sent: Friday, March 09, 2012 11:46 AM
To: django-developers@googlegroups.com
Subject: Re: authentication by email

On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant  wrote:

On 09/03/12 14:49, Tom Evans wrote:


Yes, since no one needs it. Okay no one isn't true, but no one (for true
this time) who needed it stepped up and said "I'll implement it and see 
that

it ends up in trunk"



I'm sorry, that completely mis-characterises the situation. Lots of
people want this, but every single time this has been brought up since
I started using django (1.0), a core dev or BFDL has explicitly ruled
it out, saying "we cannot do this, requires schema migration, we'll
look at it for the next version".


This is not true. There have been times when we have said we cannot
consider it right now, and that a solid proposal should be brought up at
the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the
core developers can look at it.

And every time, the proposal has either been missing or simply not been
adequate - for example, the GSoC 2010 and 2011 proposals regarding this.
Russell gave detailed feedback on why these solutions were not adequate
[1], and at other times has provided feedback on possible strategies
[2]. And the people who went away to work on the problem have gone
silent or admitted defeat. One presumes they fixed their immediate
problem in a way that would not be a general solution, and moved on, and
that is perfectly understandable. A adequate solution to this is very
hard, and probably requires solving several other big problems first
(like at least one of lazy foreign keys/virtual models/database 
migrations).


It isn't, however, impossible. Our definition of 'need' is that someone
is sufficiently motivated to overcome the obstacles, and contribute a
solution that works for other people as well as themselves.

Regards,

Luke


[1] http://goo.gl/swTpr

[2] http://goo.gl/7p1JN



I disagree. There are small problems with the User model that have not
been fixed. Every proposal you've listed does not address these
issues, but instead looks to find ways of replacing the base user
object, which is a complex and difficult project.

There is a reason why these are the proposals. Every time someone
proposes fixing these minor bugs, the cry from on high is that
instead, d.c.auth will be overhauled to allow for more customization
by the project, immediately increasing the scope and complexity. But
this fabled d.c.auth2 never appears.

In fact, your reply alludes to this. We're talking about why a field
is too short to contain valid values, and you suggest that the
solution inevitably will involve "lazy foreign keys/virtual
models/database migrations" - it's changing one line, and adding a
comment to relnotes!

We may have to agree to disagree on how easy some of these things are to 
fix.


Lets look at one isolated aspect. The User email field in d.c.auth is
too short. Emails can be up to 248 characters long, and d.c.auth only
allows 75.

Clearly, this is a bug, is wrong and should be fixed. How can we fix it?

We can alter the length of the field in the model definition. What
problems does this bring?

Users who do not manually update their database will not be able to
store longer length emails, and will get 'strange effects' when they
try - either silent truncation, or database integrity errors. How can
we mitigate this for users who refuse to update?

Provide a compat shim that resets the email length to that in 1.3, and
immediately mark it PendingDeprecation. Users who read the relnotes
and don't want to change their DB can use the shim, and have a clear
expectation of when they must have updated their database.

I still think these bug fixes are paralysed by a fear of change, and a
desire to engineer a solution that is every thing to every man. Lets
just fix these glaring bugs…

Cheers

Tom

--
You 

[1.4] SECRET_KEY deprecation is confusing...

[Nick Pope]

Hi,

There is a problem in 1.4rc2 where a missing SECRET_KEY causes Django to 
refuse to start.

According to the current version of the release notes on the website: *In 
Django 1.4, starting Django with an empty SECRET_KEY will raise a 
DeprecationWarning. In Django 1.5, it will raise an exception and Django 
will refuse to start.*
*
*
This doesn't make sense...  It currently raises DeprecationWarning which is 
an exception which causes Django to fail to start.  To trigger a 
deprecation warning while allowing execution to continue you need to use 
warnings.warn().

As things stand you are essentially implementing the behaviour for both 1.4 
*and* 1.5!

Cheers,

Nick

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/lYpYVlaGlZYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Composite Key at Europython

[Simone Federici]

I'd like speak at europython about a project on composite primary and
foreign key for Django.

https://github.com/simone/django-compositekey

This solution that I'm using on a very small realty.  I've developed using
monkey some patch because the purpose was not forking django. Is more easy
introduce a small library in a project  that a fork of django itself.

So I was preparing the paper to submit to  Europython when I saw the
konk (Michal Petrucha) fork of Django, that is envolved on "composite
key problem". [Hey Michal nice to meet you].

Now, I'd like meet someone at Europython to speak about this project, and
how the multiple primary/foreign key will be introduced in Django. Maybe in
1.5? Do you think it will be possible?

I think this is possible.

Michal do you think to fly on florence next July?
someone else wants to join the idea?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Custom permissions on proxy model no longer created in 1.4

[koenb]

Op donderdag 15 maart 2012 11:52:42 UTC+1 schreef Aymeric Augustin het 
volgende:
>
> Le 15 mars 2012 10:27, koenb a écrit :
>
>> this could very well be one of those "don't do that" things, but here is 
>> my problem.
>>
>> I have been using some specific permissions concerning the auth user model
>
> (... snip ...) 
>
> Now I was testing my project with the 1.4 RC, and it turns out those 
>> permissions are no longer created.
>>
>
> Hi Koen,
>
> At first sight, you code is valid, and this is a regression.
>
> I suppose it happened somewhere in this list:
>
> https://code.djangoproject.com/log/django/trunk/django/contrib/auth/management/__init__.py
>
> Could you open a ticket on code.djangoproject.com and set Severity to 
> "Release blocker"?
>
> Thanks,
>  
> -- 
> Aymeric.
>

Done: #17904

Koen 
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/VhZC9AxfB9sJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Custom permissions on proxy model no longer created in 1.4

[Aymeric Augustin]

Le 15 mars 2012 10:27, koenb  a écrit :

> this could very well be one of those "don't do that" things, but here is
> my problem.
>
> I have been using some specific permissions concerning the auth user model

(... snip ...)

Now I was testing my project with the 1.4 RC, and it turns out those
> permissions are no longer created.
>

Hi Koen,

At first sight, you code is valid, and this is a regression.

I suppose it happened somewhere in this list:
https://code.djangoproject.com/log/django/trunk/django/contrib/auth/management/__init__.py

Could you open a ticket on code.djangoproject.com and set Severity to
"Release blocker"?

Thanks,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Danny Adair]

On Thu, Mar 15, 2012 at 22:53, Danny Adair  wrote:
>[...]
> I'd like to see a later, "proper" auth.user that can undo that chaos.

I originally thought you intended a setting which let's the user
switch from the existing auth to an email auth with corresponding User
model.
As lame as that may be - at least a later, "proper" auth.user solution
would only have two known (shipped) auths to deal with.

Cheers,
Danny

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Danny Adair]

On Mon, Mar 12, 2012 at 16:57, Clay McClure  wrote:
>[...]
> New django projects can elect to use an entirely different pluggable auth
>[...]
> The pluggable-auth-apps fork is barely two days old, so it's still rough
> around the edges, and I've almost certainly missed some things. I haven't
>[...]

I'm sorry I don't know if I like that. I hope I understand correctly
what you're doing, and that my criticism is seen as constructive.
This sells itself as "pluggable auth" but really only provides the
originally requested auth by email, and I don't see how it could go
from there, i.e. what else would be possible (in regards to auth).
Pulling username and email out of (Base)User and then bringing one or
both of them - and the logic of which to check - back in, is not
really a pluggable auth.

It's the mixing of profile and information relevant to authentication
(and authorization - is_staff?) that's another problem of the existing
User model, and this is where this approach allows for dangerous
developments.
You've pulled those two out and said it's up to the chosen auth to
decide a) which to even include in the User model b) which is used to
authenticate and which is just "secondary" user (profile?)
information.
What about first_name and last_name? Why can't a pluggable auth dump
those from the User model? And certainly an "auth" should get to have
a say about "password".
And then... there's not much left anymore in that (Base)User model,
right... (GSoC: "reducing the user table to little more than an
identifying primary key")

Ok email auth problem solved. But now there's a simple way of
providing any User model I like, so first thing I'm going to do is to
bring in what I think the User should look like i.e. use the "auth" to
define what really is a "profile".  And so will lots of projects. "The
User model needs a username for this app to work". "The User model
needs a timezone for this app to work". etc.
I'd like to see a later, "proper" auth.user that can undo that chaos.

Cheers,
Danny

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Custom permissions on proxy model no longer created in 1.4

[koenb]

Hi all,

this could very well be one of those "don't do that" things, but here is my 
problem.

I have been using some specific permissions concerning the auth user model, 
so I created a proxy model on user like this:

class User(auth_models.User):
class Meta:
proxy = True
permissions = (
("display_users", "May display users information"),
("edit_users", "May edit users information"),
)

In 1.3 these custom permissions were created during syncdb (linked to the 
auth.User model).

Now I was testing my project with the 1.4 RC, and it turns out those 
permissions are no longer created.

This is caused by the refactor of the create_permissions code, which now 
uses get_for_models to determine the class to get the options for, but this 
returns the proxied class (auth.User), not the proxy class, so my custom 
permissions are not found and not created.

Maybe I am using the proxy model for something it was not intended for. If 
so, it might be a good idea to add a warning in the release notes about 
this, in case others are doing something similar.

BTW, thanks for yet another awesome new release.

Koen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/gdAd5dGloeoJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ANN: Django 1.4 string freeze and translation updates needed

[Aymeric Augustin]

Hello,

A second RC was just released [2]; it includes translations contributed until 
yesterday (roughly 2012-03-14 08:50:00 UTC).

If everything goes according to plan, the final 1.4 release will happen on 
March 21st. We'll probably pull the translations from Transifex on March 20th.

I'd like to draw the attention of the Russian maintainers to ticket #17901; at 
least one string appears to be off in the admin translations [3].

Thanks and keep up the good work!

-- 
Aymeric.

[1] https://www.djangoproject.com/weblog/2012/mar/14/14rc2/
[2] https://code.djangoproject.com/ticket/17901
[3] 
https://www.transifex.net/projects/p/django/resource/contrib-admin/l/ru/view/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: [GSoC 2012] Improved error reporting

[Russell Keith-Magee]

On 15/03/2012, at 1:23 PM, Boris Bobrov wrote:

> Hi!
> I'd like to participate in GSoC-2012 and the interesting task for me is [0].
> 
> What kind of plan would you expect from me? Should it be detailed ("I'll fix 
> error handling in part X by doing A") or it can be more general ("I'll fix 
> error handling in part X after reviewing A, B, C") or even move general 
> ("I'll 
> fix error handling of cases listed on [1] and some others I've met in my 
> practice")?
> 
> The problem is that I don't know all the places with such poor error 
> handling; 
> and the list on [1] is incomplete, I've met some useless error messages 
> myself, in templates mostly. Though a lot can be found by googling
> "site:stackoverflow.com django weird strange error".

Essentially, we're going to be looking for evidence that you understand the 
scope of the problem you're proposing to solve. Generic statements like "I'm 
going to fix the errors in X" aren't especially convincing by themselves. 

To put it another way: Our selection process is essentially guided by looking 
at the proposals, and determining what we (as a project) are going to get out 
of the project at the end of the GSoC. A generic plan that says "I'm going to 
spend 12 weeks fixing error messages in Django" doesn't really let us know what 
the end product will be. Will you fix 1 error? 10? 100? Will they all be in 
contrib? django.core? 

We also need to be convinced that you appear to understand the complexity (or 
lack of complexity) of the problem you're proposing to fix, and that you have a 
plan that will enable you to deliver on what you're promising. A plan that just 
says "I'm going to fix these 10 problems" without providing any details isn't 
very helpful either. Yes, it would be good to have 10 less problems -- but how 
do we know that the 10 problems can actually be fixed in 12 weeks? Or, at the 
other end of the scale -- how do we know that you're not going to be finished 
in a week?

What we really need is a list of the areas you're going to look at, and some 
sort of analysis of the source of the problems in those areas -- e.g., is it 
just a matter of the error messages being unhelpful, or is there something 
fundamental that needs to be fixed (e.g., internally generated exceptions being 
re-raised in unhelpful ways, or exceptions being raised by a side effect, 
rather than the real problem). 

You don't have to go to the level of enumerating every single error message you 
will fix (although that would certainly be nice!), but we will be looking for a 
rigorous analysis. This will require some research and elaboration on your part.

A good rule of thumb: Can you produce a convincing timeline for a 12 week 
project? If your project plan is filled with "3 weeks: Fix errors in admin", 
then you haven't provided us with any evidence that you understand the scope of 
the problem. If you can get to 1 week granularity, you're starting to be 
convincing. Granularity at the level of days would be excellent.

> Another question - can I use code written by other people as patches in 
> django 
> bugtracker for my GSoC project?

As far as I understand the rules -- yes, as long as you're also making a 
significant contribution yourself. Your project can't just be "I'm going to 
merge these 10 patches"; you need to actually produce some code of your own.

> [0]:https://code.djangoproject.com/wiki/SummerOfCode2012#Improvederrorreportin
> [1]:https://code.djangoproject.com/wiki/BetterErrorMessages
> -- 
> WBR, 
> Boris. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.