Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Carl Meyer 

On Feb 20, 2013, at 6:25 PM, Ian Kelly  wrote:
> On Feb 20, 2013 4:41 PM, "Carl Meyer"  wrote:
> > On 02/20/2013 04:25 PM, Nick Phillips wrote:
> > >> There was extensive back-and-forth discussion of this in writing the
> > >> patch. The issue is that in almost all cases the correct value of the
> > >> setting in local development and under test are different from the
> > >> correct value in production. So how much value is there in knowing the
> > >> tests pass, and/or it works locally? That doesn't really increase the
> > >> chances that you have it configured correctly in production.
> > >
> > > It would at least ensure that you were aware of it and had attempted to
> > > set it...
> >
> > That's true.
> 
> If you have a test tier where DEBUG=False, then the first request from an 
> actual browser would also detect this, would it not?
> 
Yes.

Carl

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

'Change' button for related fields.

2013-02-20 Thread Mason Staugler 
I was going to monkey patch this into our system until a coworker suggested 
contributing. This patch will add a 'change' link (next to the 'add' 
button) for related fields.

Is it a trivial patch? I have a feeling it's a Design Decision Needed and 
the docs suggested post it to this group.

Here's the patch:
https://github.com/mqsoh/django/commit/fedfe2dd41d8b74ec80240efab5b01b076fa05d4

...and this is what it looks like. The pencil will link to the change form 
for the selected object.



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

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Ian Kelly 
On Feb 20, 2013 4:41 PM, "Carl Meyer"  wrote:
>
> On 02/20/2013 04:25 PM, Nick Phillips wrote:
> >> There was extensive back-and-forth discussion of this in writing the
> >> patch. The issue is that in almost all cases the correct value of the
> >> setting in local development and under test are different from the
> >> correct value in production. So how much value is there in knowing the
> >> tests pass, and/or it works locally? That doesn't really increase the
> >> chances that you have it configured correctly in production.
> >
> > It would at least ensure that you were aware of it and had attempted to
> > set it...
>
> That's true.

If you have a test tier where DEBUG=False, then the first request from an
actual browser would also detect this, would it not?

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

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Carl Meyer 
On 02/20/2013 04:25 PM, Nick Phillips wrote:
>> There was extensive back-and-forth discussion of this in writing the
>> patch. The issue is that in almost all cases the correct value of the
>> setting in local development and under test are different from the
>> correct value in production. So how much value is there in knowing the
>> tests pass, and/or it works locally? That doesn't really increase the
>> chances that you have it configured correctly in production.
> 
> It would at least ensure that you were aware of it and had attempted to
> set it...

That's true.

>>  In the end,
>> our estimation was that requiring it to be configured in local dev and
>> testing would introduce quite a lot of hassle (and potentially a major
>> roadblock for new users), with very little gain to offset that.
> 
> What would the implications of having "localhost" in there be?

We considered this too (like I say, this question got a lot of
discussion :-) ). For people who actually connect to "localhost" in
local dev, it would be more or less the same as the current behavior.
For others (who don't), they'd have to set it.

But in the end, this just splits the difference in a way that doesn't
help. For any given user, either it "just works" for local dev (and we
thus lose the awareness benefit you mentioned above), or we force you to
deal with it all the time (and make things more of a hassle). We weighed
the options and chose to make it consistently the former.

Carl

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

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Nick Phillips 
On Tue, 2013-02-19 at 15:46 -0700, Carl Meyer wrote:
> Hi Nick,
> 
> On 02/19/2013 03:32 PM, Nick Phillips wrote:
> > I don't recall looking at the ALLOWED_HOSTS setting before. Now that I
> > do, it seems rather problematic. In particular, that host verification
> > is apparently turned off while DEBUG is True or while testing.
> > 
> > Surely this makes it impossible to test, and makes it likely that
> > misconfigurations will not be picked up until deployed to a production
> > environment.
> >
> > Given that most setups require some customisation of settings for
> > dev/staging/production/whatever environments anyway, why not leave the
> > verification on at all times and allow us to ensure we get the right
> > hosts in the right environments?
> 
> There was extensive back-and-forth discussion of this in writing the
> patch. The issue is that in almost all cases the correct value of the
> setting in local development and under test are different from the
> correct value in production. So how much value is there in knowing the
> tests pass, and/or it works locally? That doesn't really increase the
> chances that you have it configured correctly in production.

It would at least ensure that you were aware of it and had attempted to
set it...

>  In the end,
> our estimation was that requiring it to be configured in local dev and
> testing would introduce quite a lot of hassle (and potentially a major
> roadblock for new users), with very little gain to offset that.

What would the implications of having "localhost" in there be?

> Note that it isn't impossible to test, if you want to; the check is
> "disabled" under test by means of setting ALLOWED_HOSTS to ['*'] for the
> duration of the test run, so if you want tests to exercise validation
> you can just use the override_settings decorator to temporarily change
> it for a test method or test case.

Ah, thanks - I was at least missing that.


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
Faculty of Medicine, University of Otago

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

ANNOUNCE: Django 1.4.5, 1.3.7 released, fixing packaging problems

2013-02-20 Thread Jacob Kaplan-Moss 
Hi folks --

We've released two new releases today -- Django 1.4.5 and Django 1.3.7
-- that correct packaging problems in yesterday's security releases.
There's no new code; just a packaging fix.

For more details, see
https://www.djangoproject.com/weblog/2013/feb/20/updated-releases-issued/.

Sorry about the mixup!

Jacob Kaplan-Moss

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

Re: Django 1.4.4 and contrib/sessions/management/__init__.pyc

2013-02-20 Thread Carl Meyer 
We've just released 1.3.7 and 1.4.5 to correct this packaging problem:

https://www.djangoproject.com/weblog/2013/feb/20/updated-releases-issued/

Thanks for reporting it!

Carl

On 02/19/2013 08:12 PM, Nick Popoff wrote:
> I downloaded Django 1.4.4 this evening and after switching to it started
> getting the following error on my CentOS 6.3 / Python 2.6 based system:
> 
> ImportError: Bad magic number in
> /usr/lib/python2.6/site-packages/django/contrib/sessions/management/__init__.pyc

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

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Carl Meyer 


On 02/20/2013 01:58 AM, Reinout van Rees wrote:
> On 19-02-13 23:32, Nick Phillips wrote:
>> I don't recall looking at the ALLOWED_HOSTS setting before.
> 
> Should there be a note in the 1.4 docs that the default ['*'] value is a
> temporary default value? That from 1.5 onwards it will be an empty list?
> 
> https://docs.djangoproject.com/en/1.4/ref/settings/#allowed-hosts

Yes, that's a good idea for the 1.3 and 1.4 docs, thanks for the
suggestion. Done.

Carl

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

Re: clarification of API backwards-compatibility policy

2013-02-20 Thread Jannis Leidel 
On Tue, Feb 19, 2013 at 10:56 PM, Carl Meyer  wrote:

> Hi,
>
> I was just about to tell someone on IRC that Django's
> backwards-compatibility policy only applies to documented methods and
> attributes (which is how I'd always understood it), but when I actually
> went to look at the documented policy it isn't as clear as I'd hoped :/
>
> https://docs.djangoproject.com/en/dev/misc/api-stability/
>
> That says "All the public APIs – everything documented in the linked
> documents below, and all methods that don’t begin with an underscore –
> will not be moved or renamed without providing backwards-compatible
> aliases."
>
> This is a bit unclear: does it really mean _every_ method _anywhere_
> that doesn't begin with an underscore? Or does it just mean every
> non-underscore method of an otherwise-documented class, even if the
> method itself is not documented?
>
> Either way, I think it would be clearer (and more accurate to actual
> practice) if we removed all mention of underscores in this document (or
> even explicitly said that we don't generally use the underscore
> convention), and clarified that back-compat applies only to documented
> modules, classes, methods, and attributes.
>
> Thoughts?
>

+1

Jannis

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

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

2013-02-20 Thread Reinout van Rees 

On 19-02-13 23:32, Nick Phillips wrote:

I don't recall looking at the ALLOWED_HOSTS setting before.


Should there be a note in the 1.4 docs that the default ['*'] value is a 
temporary default value? That from 1.5 onwards it will be an empty list?


https://docs.djangoproject.com/en/1.4/ref/settings/#allowed-hosts


Reinout

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

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