Fwd: Break with Django SVN r6718

[Josh Stone]

Hi all,

I'm having problems using Review Board with recent Django revisions, and I'm hoping that this list can help.  Please see below for the previous discussion, but the gist is that with Django r6718 (and later), I'm getting exceptions when urls.py tries to access site settings.  I did some debugging, and it seems that urls.py is only getting the default settings, so all of the custom settings are missing from the object.

1. If I run " ./manage.py runserver 0.0.0.0:8080", I get exceptions.
2. If I run "env DJANGO_SETTINGS_MODULE=reviewboard.settings ./manage.py runserver 0.0.0.0:8080", I get exceptions.
3. If I run "./manage.py runserver --settings=reviewboard.settings 0.0.0.0:8080", it works fine!

Everything works fine though with Django r6717, so something in that change must have broken this.  It's not a big change, but I'm at a loss as to what the problem is.  The Review Board developers are not able to reproduce this, but they're using Python 2.5 and mine is Python 2.4.

Any ideas?

Thanks,

Josh

---------- Forwarded message ----------
From: Christian Hammond < chi...@chipx86.com>
Date: Nov 30, 2007 3:05 PM
Subject: Re: Break with Django SVN r6718
To: revie...@googlegroups.com


That's very strange... I don't have any ideas. It's working perfectly fine here. There must be some subtlety that we're missing.

I am using Python 2.5, though. Maybe there's some bug they introduced with 2.4.

Christian

On Nov 30, 2007 2:57 PM, Josh Stone <cuv...@gmail.com > wrote:

Yes, this is with devserver.sh.  I just tried a completely clean copy, to make sure it's not my settings, and I still get the exception.  settings_local.py is exactly the same as the template except I changed it to sqlite3 instead of mysql.

Here's the latest I tried: Review Board r1038, djblets r11659, Django r6782, Python 2.4.3

Any ideas?

Josh

On Nov 29, 2007 10:03 PM, Christian Hammond <chi...@chipx86.com> wrote:

This is with devserver.sh? I just synced to 6718 and I'm having no problems there either. Also tried the latest revision and it's working too.

Christian

On Nov 29, 2007 6:22 PM, Josh Stone < cuv...@gmail.com> wrote:

When I run Review Board (r1032) with Django r6718 or later, I see this exception in the browser:

Error while importing URLconf 'reviewboard.urls ': 'Settings' object has no attribute 'BUILTIN_AUTH'

What's weird is that the debug output dumps the settings down below, and BUILTIN_AUTH looks fine.  So I stepped into reviewboard.urls with the debugger, and found that the 'settings' object was missing everything from settings.py and settings_local.py, even though they all show up in the exception dump!

Django r6717 works fine, but r6718 breaks (gotta love git-bisect).  However, if I pass "--settings= reviewboard.settings" to manage.py, everything works fine.

Has anyone else seen this?  I would guess that it's a Django bug, not RB's, but hopefully someone more familiar with Django innards can take a look...

Thanks,

Josh

--

Christian Hammond - chi...@chipx86.com
VMware, Inc.

--
Christian Hammond - chi...@chipx86.com
VMware, Inc.

[Malcolm Tredinnick]

On Fri, 2007-11-30 at 16:18 -0800, Josh Stone wrote:
> Hi all,
>
> I'm having problems using Review Board with recent Django revisions,
> and I'm hoping that this list can help. Please see below for the
> previous discussion, but the gist is that with Django r6718 (and
> later), I'm getting exceptions when urls.py tries to access site
> settings. I did some debugging, and it seems that urls.py is only
> getting the default settings, so all of the custom settings are
> missing from the object.
>
> 1. If I run "./manage.py runserver 0.0.0.0:8080", I get exceptions.
> 2. If I run "env
> DJANGO_SETTINGS_MODULE=reviewboard.settings ./manage.py runserver
> 0.0.0.0:8080", I get exceptions.
> 3. If I run "./manage.py runserver --settings=reviewboard.settings
> 0.0.0.0:8080", it works fine!

Try to reduce the problem to something a bit simpler, since there's a
large package involved here (that I, and probably a lot of other people
on this list, know nothing about).

Does just creating a simple Django project from scratch work for you
(e.g. the tutorial application)?

What operating system are you running on (there could well be Windows
vs. Mac vs. Linux vs. OS/2 differences)? What exceptions do you get?
Just the standard "can't find settings" exception, or something else?

Malcolm

[Josh Stone]

I just found that commit 6871 fixed the problem by reverting 6718:
"Undid [6718], as it broke 'django-admin.py runserver' for a
reason I haven't figured out yet"

But since there still seems to be some mystery, I went on with some
debugging on 6718 anyway below.

On Dec 2, 6:53 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

> Try to reduce the problem to something a bit simpler, since there's a
> large package involved here (that I, and probably a lot of other people
> on this list, know nothing about).

I'm sorry, you're right, I should have pared down the problem first.

> Does just creating a simple Django project from scratch work for you
> (e.g. the tutorial application)?

I started a new 'mysite' as described in the beginning of the
tutorial, and verified that I could get the "Welcome to Django" page.
Then I made the following simple changes:

Add to settings.py:
FOOBAR = 42

Add to urls.py:
from django.conf import settings
print settings.FOOBAR

Then when I visit the site, I get an ImproperlyConfigured exception,
"Error while importing URLconf 'mysite.urls': 'Settings' object has no
attribute 'FOOBAR'". But if I add "--settings=mysite.settings" to the
manage.py command line, then it works fine.

> What operating system are you running on (there could well be Windows
> vs. Mac vs. Linux vs. OS/2 differences)? What exceptions do you get?
> Just the standard "can't find settings" exception, or something else?

This is RHEL5.1, with python-2.4.3-19.el5. The exception is always
the same, as quoted above.

Let me know if I should try anything else. Otherwise I'll just use
Django after 6718 was reverted, where things are fine for me.

Josh

[Todd O'Bryan]

Crapola.

r6718 was a patch I wrote. Without the patch you only get app-defined
commands if you use manage.py. With django-admin.py, you don't get
app-defined commands, even if you specify a --settings=path module.

I just tried the steps you mentioned and everything works fine, both
in Python 2.4 and 2.5:

tobryan1@200-TC-TOBRYAN1:~/Desktop/mysite$ python2.4
Python 2.4.4 (#2, Oct 4 2007, 22:02:31)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
tobryan1@200-TC-TOBRYAN1:~/Desktop/mysite$ python2.4 manage.py runserver
Validating models...
0 errors found

Django version 0.97-pre-SVN-6718, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
42
[09/Dec/2007 09:11:40] "GET / HTTP/1.1" 404 2053
tobryan1@200-TC-TOBRYAN1:~/Desktop/mysite$ python
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
tobryan1@200-TC-TOBRYAN1:~/Desktop/mysite$ python manage.py runserver
Validating models...
0 errors found

Django version 0.97-pre-SVN-6718, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
42
[09/Dec/2007 09:12:17] "GET / HTTP/1.1" 404 2053

Can you provide any other debugging information that might help me
narrow down the problem?

Adrian, what errors were you seeing that caused the revert?

Todd
(Sorry it took me so long to get to this--teaching has been a bear recently.)

[Josh Stone]

I'm not sure what else to try, but let me know if there's something specific you want to see.  Here's a similar session to what you ran, but note that I demonstrate 6717 working first.  Also note that I'm running Django from '~/mysite/django'; I don't have any Django version installed in site-packages.

~/mysite$ rpm -q python
python-2.4.3-19.el5
~/mysite$ python
Python 2.4.3 (#1, Dec 11 2006, 11:38:52)
[GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2

Type "help", "copyright", "credits" or "license" for more information.
>>>

~/mysite$ ./manage.py runserver

Validating models...
0 errors found

Django version 0.97-pre-SVN-6717, using settings ' mysite.settings'

Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
42

[10/Dec/2007 12:59:53] "GET / HTTP/1.1" 404 2053
~/mysite$ (cd django && svn up -r6718)
U    core/management/__init__.py
Updated to revision 6718.
~/mysite$ ./manage.py runserver

Validating models...
0 errors found

Django version 0.97-pre-SVN-6718, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

[10/Dec/2007 13:00:40] "GET / HTTP/1.1" 500 47596
~/mysite$ ./manage.py runserver --settings=mysite.settings

Validating models...
0 errors found

Django version 0.97-pre-SVN-6718, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
42

[10/Dec/2007 13:01:07] "GET / HTTP/1.1" 404 2053

Josh

> attribute 'FOOBAR'".  But if I add "--settings= mysite.settings" to the

[Todd O'Bryan]

Hmm. What you said about not having Django installed in site-packages
makes me think...

What does your PYTHONPATH environment variable have in it?

Do you possibly have the current directory listed before the path to
Django? Because if you try to

from django.conf import settings

before your settings module has been identified, weird things might
happen. (I don't know what exactly...I'm grasping at straws at the
moment.)

Thanks,
Todd

[Josh Stone]

On Dec 10, 2007 3:03 PM, Todd O'Bryan <toddo...@gmail.com> wrote:

Hmm. What you said about not having Django installed in site-packages
makes me think...

What does your PYTHONPATH environment variable have in it?

I wasn't setting PYTHONPATH to anything.  Normally packages are picked up just fine when they're in the current directory.  I put Django there because I would rather not add pre-release software to site-packages.

I had a hunch that having Django in the current directory was the problem, and now that seems to be confirmed.  Here are some more trials:

• Django in site-packages only: works
• Django in site-packages and in $PWD: fails
• Django in $SOMEDIR and PYTHONPATH=$SOMEDIR: works
• Django in $SOMEDIR and in $PWD, and PYTHONPATH=$SOMEDIR: fails
• Django in $PWD only: fails
• Django in $PWD and PYTHONPATH=$PWD: fails
  

Any of the failure cases will work if I add '--settings=mysite.settings' to the command line, or if I use a revision that doesn't have your 6718 change.

Do you possibly have the current directory listed before the path to
Django? Because if you try to

from django.conf import settings

before your settings module has been identified, weird things might
happen. (I don't know what exactly...I'm grasping at straws at the
moment.)

It does look like the settings object that I get in urls.py has only the default settings and none of the local settings.  But I don't know how 6718 changed this behavior, or why adding --settings fixes it.


Josh