Re: authentication by email

2012-03-09 Thread Danny Adair 
On Fri, Mar 9, 2012 at 20:01, Donald Stufft  wrote:
> The major issue is that there is no way to do schema migrations in core
> (currently). So there's no way to handle increasing the length of the
> username field.

I don't understand what the "username" field length has to do with it.

And I think that's also the problem with Clay's original post:
Do you want to authenticate against email or also change the User model?

What if I want to authenticate against email but still have a username ("nick")?
Another setting?

An auth backend that checks against the email address (which is
already in the User model just like username) _is_ simple.
Rapid and simple would be to _ship_ such a backend in contrib.auth.backends.
Then it would really just be a single setting (AUTHENTICATION_BACKENDS
= ('django.contrib.auth.backends.EmailBackend',)).
The only thing left would be the label on the login template in my
naive understanding. (another one-liner I believe)

So I agree it would be nice and useful, but where's the monkeypatching.
If you want to authenticate against email _and_ take the "username"
out of the model, it's that second part that's the problem. That's
where I believe a set of settings and conditions is a kneejerk
workaround.

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

2012-03-09 Thread Florian Apolloner 
Hi,

On Friday, March 9, 2012 6:54:16 AM UTC+1, Clay McClure wrote:
>
> if settings.AUTH_EMAIL_AUTHENTICATION:
>

Hell, not another ugly setting like this.

Should these things really take five years? What happened to pragmatic?
>

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"


Regards,
Florian

-- 
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/-/dqX87TxXVyQJ.
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

2012-03-09 Thread Danny Adair 
On Fri, Mar 9, 2012 at 21:13, Florian Apolloner  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"

It's the "required" of username that's the problem if you don't want a
username at all when authenticating against email.
It would have to be not required and check required fields in clean()
where the backend could be asked what's really required.
And there's Mr. Schema Migration again...

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: The model class should have default ``__cmp__`` method.

2012-03-09 Thread Łukasz Rekucki 
On 9 March 2012 06:15, Λlisue  wrote:
> I have the following codes for testing model and it's works correctly in
> Django 1.3 + Python 2.7 without unittest2::
>
> # in method of TestCase subclass ---
> user1 = User.objects.create_user(username='user1',
> email='us...@test.com', password='password')
> user2 = User.objects.create_user(username='user2',
> email='us...@test.com', password='password')
>
> self.assertItemsEqual(User.objects.all(), [user1, user2])
> #---
>
> However the code raise ``AssertionError: Sequences differ: ...`` in
> Django 1.3 + Python 2.6 or Django 1.3 + Python 2.7 + unittest2. (well
> but I have no idea why the code above works with Django 1.3 + Python 2.7
> without unittest2)

Since 1.3 Django ships with unittest2 library (see
django.utils.unittest), so if there are no
other versions of unittest2 installed, it will use that (which is a
verbatim copy of unittest2==0.5.1).

Python 2.7 seems to have a bit different implementation of that
method, but it uses things like Counter.

>
> This happen because unittest2 or whatever does ``sorted(expected_seq)``
> in ``assertItemsEqual`` method but they don't know how to sort the
> instances of model class.

Actually, assertItemsEqual handles unorderable and unhashable items,
if you take a look at it's source code. The py2.7 version should too.
Didn't have time to check this, but it looks like a bug in unittest2.

> To solve this problem, I simply add
> ``__cmp__`` method to Model class like::
>
> # somewhere but called after Django has correctly configured ---
> from django.db.models import Model
>
> if not hasattr(Model, '__cmp__'):
>    Model.__cmp__ = lambda self, other: cmp(self._get_pk_val(),
> other._get_pk_val())
> #---
>

Apart from __cmp__ being deprecated, this isn't really correct even
for testing (the model can have an UUIDField as it's pk instead of a
sequential integer).

For making assertions about QuerySets, there already is
assertQuerysetEqual(), so -1 on adding __cmp__ to Model.

-- 
Łukasz Rekucki

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

2012-03-09 Thread Tino de Bruijn 
My django-email-login app (
https://bitbucket.org/tino/django-email-login/overview) does this by
putting a hash of the email adress in the username field. It isn't as nice
as it could be, but it works.

I would really like to see this solved another way, but it is a hard
problem with the current restrictions.

Tino

On Fri, Mar 9, 2012 at 09:23, Danny Adair  wrote:

> On Fri, Mar 9, 2012 at 21:13, Florian Apolloner 
> 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"
>
> It's the "required" of username that's the problem if you don't want a
> username at all when authenticating against email.
> It would have to be not required and check required fields in clean()
> where the backend could be asked what's really required.
> And there's Mr. Schema Migration again...
>
> 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.
>
>

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

2012-03-09 Thread Clay McClure 
On Fri, Mar 9, 2012 at 3:23 AM, Danny Adair wrote:


> It's the "required" of username that's the problem if you don't want a
> username at all when authenticating against email.
> It would have to be not required and check required fields in clean()
> where the backend could be asked what's really required.
>

That's one problem. Another problem is that the default User.email field is
not unique, is not required, is not indexed, and may be too short.

And there's Mr. Schema Migration again...
>

Who's talking about a migration? I'm asking for something that will work
for *new* installations; existing installations can continue authenticating
against usernames  for all I care :)

Moreover, I'm thoroughly frustrated by the fact that developers *do* bring
working solutions to the table (in the form of patches in trac), but the
core developers won't integrate them, either because it's not the right
time (usually right before a release), because the patch isn't general
enough, or because the patch doesn't meet some absurdly high bar of
quality. I understand that they have a commitment to backwards
compatibility and that accepting a mediocre patch could mean maintaining it
for life, but I like to think that—with a framework that purports to be
"pragmatic"—there are pragmatic solutions to these problems—and not,
"sorry, it's not perfect, it can't go in."

The GSoC page (
https://code.djangoproject.com/wiki/SummerOfCode2011#Enhancedauth.user) is
a frustrating read. It goes on and on about how hard the problem is and how
wrong your solution is, but doesn't provide any detail as to why it's hard
or why it's wrong. Ticket #3011 was rejected without much of a reason. HM
asked for an explanation both in the ticket itself and on django-dev; no
explanation was ever given.

The GSoC page also mentions migrations:

"How can we roll out a new/modified User model without requiring almost
every Django application on the planet to undergo a complex database
modification?"

But again, why do existing databases have to change? We're talking about
leaving User as-is, by default, but providing a mechanism to use a
different model if the developer chooses. Clearly this is a decision the
developer would not take lightly: you're not going to change from username
authentication to email authentication without a bit of thought. Projects
that are using username authentication will continue to use username
authentication, but at least new projects that want/need email
authentication will be able to do that without monkey patching models.

The GSoC page also mentions Lazy Foreign Keys, but no explanation is given
there or in the linked django-dev thread as to why LFKs are required to
implement a pluggable User model. LFK may be the panacea of code
cleanliness and virtual awesomeness, but those of us with deadlines just
need to authenticate against email addresses, like, five years ago.

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.

[Minor Issue]: contrib/auth still uses send_mail as compared to EmailMessage

2012-03-09 Thread Karthik Abinav 
Hi,

   The contrib/auth still uses send_mail for sending an email .But since,
send_mail is currently frozen, It is better to invoke EmailMessage directly
from contrib/auth instead of going through send_mail and that in turn
invoking EmailMessage. I have submitted a ticket along with a patch for
this at
http://code.djangoproject.com/ticket/17862

Thanks,
Karthik  Abinav

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

2012-03-09 Thread Tom Evans 
On Fri, Mar 9, 2012 at 8:13 AM, Florian Apolloner  wrote:
>> Should these things really take five years? What happened to pragmatic?
>
>
> 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".

At this point, the discussion is stopped. Once a proposal has the
smack down from a BFDL, what point is there trying to get it
integrated?

The next version comes, has it been addressed? No. Will it be
addressed in 1.4? No. Will it be addressed in 1.5? Possibly, but I
doubt it.

At $JOB we've given up waiting for some trivial changes, and have
simply patched django to not have these silly, arbitrary and incorrect
requirements¹ on email address and username.

We live in the real world, we have to be able to handle email
addresses that are of a valid length. We cannot tell a paying customer
"I'm sorry, your email address is too long, do you have one under 75
characters?"

It's a really invalid position to take, knowing something is broken
and incorrect, but not fixing it because 'change is hard'.

Cheers

Tom

¹ Here is my list of things that are broken with d.c.auth:

1) Length and character restrictions on username field. If I want to
use emails address as usernames, or usernames with spaces, the choices
made at lawrence.com 3+ years ago should not restrict me.
2) Email address fields must be large enough to hold valid email
addresses - that's 254 characters.

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

Language Translation

2012-03-09 Thread Vishnu vg 
Hi Friends,

I have a cms based existing django site. I want to translate it to german
or other language, Please suggest which is the best method?


-- 
Regards

Vishnu V.G
Software Programmer
Mobile : 8714321452(Docomo)

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

2012-03-09 Thread Luke Plant 
On 09/03/12 09:37, Clay McClure wrote:

> Who's talking about a migration? I'm asking for something that will work
> for *new* installations; existing installations can continue
> authenticating against usernames  for all I care :)
> 
> Moreover, I'm thoroughly frustrated by the fact that developers *do*
> bring working solutions to the table (in the form of patches in trac),
> but the core developers won't integrate them, either because it's not
> the right time (usually right before a release), because the patch isn't
> general enough, or because the patch doesn't meet some absurdly high bar
> of quality. I understand that they have a commitment to backwards
> compatibility and that accepting a mediocre patch could mean maintaining
> it for life, but I like to think that—with a framework that purports to
> be "pragmatic"—there are pragmatic solutions to these problems—and not,
> "sorry, it's not perfect, it can't go in."

What you are really saying is this: being pragmatic means that we
prioritise *your* immediate need above the need to keep the code and the
docs maintainable, and above the need to maintain compatibility with
existing installations.

There are a million-and-one hacks we would add if we took that approach,
and Django would have a million-and-one more bugs, or possibly much
worse - if you add just 10 boolean switches like the one you suggested
in an earlier email, you've got over 1000 combinations to test and
debug. The only way to avoid that in a framework like Django is well
defined APIs for components. No-one has brought such a thing to the
table and seen it through, that's why it hasn't come in.

I believe that all the problems you have can be solved already:

 - you can write your own authentication backend to authenticate
   by email

 - you can write your own login and account creation views

 - you can even override admin views by inserting items into
   urls.py


Yes, these are all more-or-less hacky. And they have problems. For
instance, what if you have two accounts with the same email address? (I
have that in some of my Django projects, BTW). The current code allows
it, so we can't change anything that would make it impossible, at either
the DB level or the Python level. This is the kind of issue that means
you can't just use the existing models.

A full and correct solution that didn't introduce dozens of new bugs is
quite hard - and I'm talking about just the code required to fix this
one feature for you, without doing anything more generally useful.

That is why we're not going to put hacks like this in core - we would
have to support these hacks for at least 3 versions if we did. We are
interested in *removing* existing hacks from our code base, and this is
vital if Django is going to see increases in features and functionality.
We are not interested in adding more hacks.

We also will refuse to litter our documentation with things like: "if
you've got this setting, it does this, otherwise you get this other
behaviour, and you've got to watch out for all these bugs because this
is a gross hack".

> The GSoC page
> (https://code.djangoproject.com/wiki/SummerOfCode2011#Enhancedauth.user)
> is a frustrating read. It goes on and on about how hard the problem is
> and how wrong your solution is, but doesn't provide any detail as to why
> it's hard or why it's wrong.

It does provide detail - it gives a list of issues you have to consider,
and tells you where to search for the other issues.

Some examples from a quick Google groups search for "auth User":

http://goo.gl/swTpr

http://goo.gl/fFlKh

These provide a lot of detail.

> Ticket #3011 was rejected without much of a
> reason. HM asked for an explanation both in the ticket itself and on
> django-dev; no explanation was ever given.

I don't know what thread you are talking about. Hanne Moa brings up the
subject here and gets two replies from Russell:

http://goo.gl/7p1JN

Regards,

Luke

-- 
"I imagine bugs and girls have a dim suspicion that nature played a
cruel trick on them, but they lack the intelligence to really
comprehend the magnitude of it." (Calvin and Hobbes)

Luke Plant || http://lukeplant.me.uk/

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

2012-03-09 Thread Tom Evans 
On Fri, Mar 9, 2012 at 3:36 PM, Luke Plant  wrote:
> What you are really saying is this: being pragmatic means that we
> prioritise *your* immediate need above the need to keep the code and the
> docs maintainable, and above the need to maintain compatibility with
> existing installations.
>
> There are a million-and-one hacks we would add if we took that approach,
> and Django would have a million-and-one more bugs, or possibly much
> worse - if you add just 10 boolean switches like the one you suggested
> in an earlier email, you've got over 1000 combinations to test and
> debug. The only way to avoid that in a framework like Django is well
> defined APIs for components. No-one has brought such a thing to the
> table and seen it through, that's why it hasn't come in.
>
> I believe that all the problems you have can be solved already:
>
>  - you can write your own authentication backend to authenticate
>   by email
>
>  - you can write your own login and account creation views
>
>  - you can even override admin views by inserting items into
>   urls.py
>

Even with these things, you are limited by the length of the username
field, the length of the email field, and the arbitrary restrictions
on what consists a username.

The length restrictions could be fixed straight away, and a note added
to the next relnotes informing users that the field has changed in
size. If they do not update their DB structure, then depending on the
database used, they will either get errors when a field value is
longer than the old limit, or silent truncation.

It's not ideal, but it doesn't cause any major problems for anyone who
reads the relnotes, and it will have to be done at some point anyway.
Even if Django did have schema migrations, the same behaviour would
occur for anyone who read the relnotes and did not apply the
migration, and many users with 'interesting' DB structures would not
be able to simply apply schema migrations either, so they would have
to do it by hand anyway.

It feels to me that only fear of change and how to manage that change
is what is stopping d.c.auth from being fixed.

>
> Yes, these are all more-or-less hacky. And they have problems. For
> instance, what if you have two accounts with the same email address? (I
> have that in some of my Django projects, BTW). The current code allows
> it, so we can't change anything that would make it impossible, at either
> the DB level or the Python level. This is the kind of issue that means
> you can't just use the existing models.
>

Good for you! I don't see that as an issue. If you are using email
address as a unique name for identifying a user, we already have a
column for that, it's called username, and it has some of the right
semantics (unique, indexed field). It is the arbitrary length and
content restrictions that stop this from happening right now.

I don't see why wanting to use email address as the unique identifier
and username for a user requires any modification to the database,
apart from (as I keep repeating) removing the arbitrary length and
content restrictions on username.

> A full and correct solution that didn't introduce dozens of new bugs is
> quite hard - and I'm talking about just the code required to fix this
> one feature for you, without doing anything more generally useful.
>
> That is why we're not going to put hacks like this in core - we would
> have to support these hacks for at least 3 versions if we did. We are
> interested in *removing* existing hacks from our code base, and this is
> vital if Django is going to see increases in features and functionality.
> We are not interested in adding more hacks.
>
> We also will refuse to litter our documentation with things like: "if
> you've got this setting, it does this, otherwise you get this other
> behaviour, and you've got to watch out for all these bugs because this
> is a gross hack".
>

I agree with this 100%. d.c.auth needs to be fixed, not have many
different settings that alter it's behaviour.

Cheers

Tom

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

2012-03-09 Thread Luke Plant 
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

-- 

Luke Plant || http://lukeplant.me.uk/

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

2012-03-09 Thread Tom Evans 
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 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

2012-03-09 Thread Joe & Anne Tennies 
While, I generally agree with the current approach, especially this close
to release. I'm going to play devil's advocate for a bit.

Schema migrations have been talked about for quite a while. There are at
least 3 external implementations I know of: South, nashvegas, and
django-evolution. I'm unsure of the status of django-evolution, but the
other two appear quite active.

A concern in my mind is that all three go off and do things totally
different ways, and the migration path to a common standard is more
difficult.

I love the idea of not choosing a tool to make the migrations, but instead
add to the ability to execute migrations. Now comes the conversation of
what that means. I would love to try to get this in to Django 1.5.

*Now on to the meat of what I really want:*
Is there something along the lines of the GNOME design group for Django?
(example: https://live.gnome.org/Design/Apps/Web). I'd love a template for
the wiki or even better an app to discuss these things. If only we had some
web developers ;) So, is there a sanctioned tool already out there? Or
should I start building up a page on the wiki for this? I think most things
become much easier once one gets a blueprint and requirements for what the
design goals are. Especially if one can get an initial "this looks
acceptable" by a core committer before "wasting one's time" because the
requirements weren't even correct.

Does github or bitbucket have such a feature I don't know about? Does
launchpad.net blueprints meet this? Is there some other place I don't know
about that someone could point me to?

On Fri, Mar 9, 2012 at 9:52 AM, 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
>
> --
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> 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.
>
>


-- 
Joe & Anne Tennies
tenn...@gmail.com

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

2012-03-09 Thread Łukasz Rekucki 
On 9 March 2012 17:46, Tom Evans  wrote:
>
> 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.

The latest RFC[1] actually specifies this as 256 *octets* with max of
64 octets for the local part and 255 octets for the domain name. So
248 *characters* would actually be incorrect and all the tedious and
error prone fixing of every Django instance would just get wasted.

I don't really think this is a "fear of change" case. It's more of "we
don't want to have to fix this again" thing.

[1]: http://tools.ietf.org/html/rfc5321#section-4.5.3.1.1

-- 
Łukasz Rekucki

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

2012-03-09 Thread Tom Evans 
2012/3/9 Łukasz Rekucki :
> On 9 March 2012 17:46, Tom Evans  wrote:
>>
>> 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.
>
> The latest RFC[1] actually specifies this as 256 *octets* with max of
> 64 octets for the local part and 255 octets for the domain name. So
> 248 *characters* would actually be incorrect and all the tedious and
> error prone fixing of every Django instance would just get wasted.
>

Sorry, 248 was a typo. If you look at my earlier reply in this thread,
I had correctly stated the maximum length of an email address as 254
*characters*.

If you check two paragraphs later in the RFC that you linked to, you
would see confirmation of this:

http://tools.ietf.org/html/rfc5321#section-4.5.3.1.3

You may also need to remind yourself what the definition of a path is.

As all email headers are either 7 or 8 bit encodings, describing 254
octets as 254 characters is perfectly valid.

None of this changes that django keeps shipping with bad defaults.
This was brought up for 1.1, 1.2, 1.3 and now 1.4.

Cheers

Tom

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

2012-03-09 Thread Łukasz Rekucki 
On 9 March 2012 21:10, Tom Evans  wrote:
> 2012/3/9 Łukasz Rekucki :
>> On 9 March 2012 17:46, Tom Evans  wrote:
>>>
>>> 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.
>>
>> The latest RFC[1] actually specifies this as 256 *octets* with max of
>> 64 octets for the local part and 255 octets for the domain name. So
>> 248 *characters* would actually be incorrect and all the tedious and
>> error prone fixing of every Django instance would just get wasted.
>>
>
> Sorry, 248 was a typo. If you look at my earlier reply in this thread,
> I had correctly stated the maximum length of an email address as 254
> *characters*.
>
> If you check two paragraphs later in the RFC that you linked to, you
> would see confirmation of this:
>
> http://tools.ietf.org/html/rfc5321#section-4.5.3.1.3
>
> You may also need to remind yourself what the definition of a path is.

And RFC 3696 originally claimed it's 320. Even after errata it still
says 256, but you are right that 254 is probably more correct.

>
> As all email headers are either 7 or 8 bit encodings, describing 254
> octets as 254 characters is perfectly valid.

UTF-8 is an 8-bit encoding that doesn't map octets to characters, so
no. But that's not really the point I wanted to make.

My point is that this kind of things change and we should have tools
to deal with that. We already have the exact same problem with IPv6
and contrib.comments, it's just people didn't noticed it yet as much.
Doing this by hand every time isn't very effective. Django needs
schema migrations.

As for the "design page" that Joe mentioned, the GSOC description is a
good start:

https://code.djangoproject.com/wiki/SummerOfCode2012#Enhancedauth.user

-- 
Łukasz Rekucki

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

2012-03-09 Thread Luciano Pacheco 
2012/3/10 Łukasz Rekucki 

> On 9 March 2012 21:10, Tom Evans  wrote:
> > 2012/3/9 Łukasz Rekucki :
> >> On 9 March 2012 17:46, Tom Evans  wrote:
>
[...]

>  My point is that this kind of things change and we should have tools
> to deal with that. We already have the exact same problem with IPv6
> and contrib.comments, it's just people didn't noticed it yet as much.
> Doing this by hand every time isn't very effective. Django needs
> schema migrations.
>
[...]

The tool for migration can be simple as docs/release note or release
warning :-) ?

We change the database schema and provide the SQL scripts to migrate the 4
supported backends (sqlite, mysql, postgres and oracle). This script are
needed "only" for upgrade projects, new projects it's just a normal path.

Is that hard, inconvenient or bad?

In my humble opinion it's simple and pragmatic.

[],
-- 
Luciano Pacheco
blog.lucmult.com.br

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

LiveServerTestCase

2012-03-09 Thread Justin Holmes 
Julien, et. al.,

Seriously.  Thank you.  Amazing.



-- 
Justin Holmes

Head Instigator, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Just a crazy idea..

2012-03-09 Thread h3 
First a little context..

I've been on the django-dev mailing list for quite a while .. since
about 1.0. I'm usually relatively quiet unless I think I have a good
insight about an issue. It's been a great source of learning, but also
a good way to notice recurring patterns.

On the other hand, I've also been working on a Django development
environment for the last few months. It will cut down a lot of
annoying, redundant and harder parts that keeps the bar of Django
development so high. Ultimately the goal is to bring it to a point
where I can hire a designer, set up a Linux virtual machine on his
workstation and make him work on Django sites with a few simple
commands. He has no needs to know about Python, buildout, package
management and other stuff like that. The project is actually a lot
more than that and I will eventually announce it officially [1], but
that's not the point of my email today.

Today I feel the need to share an idea that came from the context
described above and that's been in the back of my head for the last
couple of weeks.

This idea could;

 - Make new features testing a lot more thorough before they are
merged them to trunk
 - Make it possible to actually measure a feature's popularity before
merging them to trunk
 - Make it a lot easier for the community to test new features and use
them long before they hit the trunk
 - Allow people to actually use features that has been rejected for
whatever reason (and that aren't implementable as third party)
 - Increase django's development pace and contributions

And this idea is just: a patch server.

Imagine a site where developers can browse, upload, rate and comment
patches. Something like django snippets, but instead of snippets, it's
patches for django.

A developer can upload a patch (linked or not to a ticket), specify
the django version with which it is compatible and add revisions.
Other users can rate, comment and propose revisions.

Finally, a buildout extension (or other automation mechanisms) could
be created and would allow to easily load and apply patches at
installation time.

In my dreams, applying a patch to a django installation would be
simple as editing a buildout.cfg and add those lines:

[django_patches]
email_username = http://server.com/user/email_username/ rev=12
no_admin = http://server.com/anotheruser/no_admin/

It would make the future development of django a lot more community
centric, more tested and more discussed.

To eager developers who wants new feature implemented in core, we
could just say "go on, make a patch and prove your point" instead of
debating it on a mailing list.

Other people could then try it, use it and improve it before it is
implemented in core.

Like I said, just a crazy idea .. or a cool GSoC project ? :)

Unfortunately I'm too busy to make it myself.. But if a majority think
it's a good idea and some developers wants to make it happen, I will
find a server to host it.

 [1] For the curious, the client part is getting quite stable
lately. We use it on a couple of projects and the number of saved
keystrokes is pretty amazing so far: https://github.com/h3/django-duke-client

--

Maxime Haineault

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

[GSoc 2012]: Want to work on keeping django code uptodate with the best practices

2012-03-09 Thread Karthik Abinav 
Hi,

  I was looking through the google summer of code 2012 wiki page and found
the "Best practices updates" problem interesting and would like to work
towards it. It would be really nice, if someone could explain in more
detail as to what exactly is expected there. I am moderately comfortable
with the code base. So, references to code and the problems along the way
would also be useful.

Thanks,
Karthik Abinav

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