I can see some differences between the Python Path for the dev server
(manage.py runserver) and apache/mod_python.  I created an error in a
template using an invalid tag so the Django pretty error screen
appears.  Using the development server I see:

Python Path:    ['/home/django/proj/loan', '/usr/lib/python25.zip', '/
usr/lib/python2.5', etc...

When setting up my apache conf according to the documentation, the
Python path looks like this:

Python Path:    ['/home/django/proj/', '/usr/lib/python25.zip', '/usr/
lib/python2.5', etc...

If I set the PythonPath in my apache conf like this, _______the site
works_____:

PythonPath "['/home/django/proj','/home/django/proj/loan'] + sys.path"

Thoughts?

On Aug 29, 11:51 am, lingrlongr <[EMAIL PROTECTED]> wrote:
> Thanks Malcolm.  How do I choose which version I want to use?
>
> I just don't understand it.  Maybe some errors will help...
>
> With DEBUG = True, I don't get any useful information.  So I turn that
> off and now I get this traceback:
>
> Traceback (most recent call last):
>
>   File "/usr/local/python/lib/python2.5/site-packages/mod_python/
> importer.py", line 1537, in HandlerDispatch
>     default=default_handler, arg=req, silent=hlist.silent)
>
>   File "/usr/local/python/lib/python2.5/site-packages/mod_python/
> importer.py", line 1229, in _process_target
>     result = _execute_target(config, req, object, arg)
>
>   File "/usr/local/python/lib/python2.5/site-packages/mod_python/
> importer.py", line 1128, in _execute_target
>     result = object(arg)
>
>   File "/usr/local/python/lib/python2.5/site-packages/django/core/
> handlers/modpython.py", line 210, in handler
>     return ModPythonHandler()(req)
>
>   File "/usr/local/python/lib/python2.5/site-packages/django/core/
> handlers/modpython.py", line 183, in __call__
>     response = self.get_response(request)
>
>   File "/usr/lib/python2.5/site-packages/django/core/handlers/
> base.py", line 128, in get_response
>
>   File "/usr/lib/python2.5/site-packages/django/core/handlers/
> base.py", line 159, in handle_uncaught_exception
>
>   File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py",
> line 281, in resolve500
>
>   File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py",
> line 270, in _resolve_special
>
>   File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py",
> line 261, in _get_urlconf_module
>
>   File "/home/modunique/proj/loan/urls.py", line 7, in <module>
>     from loan.amortization.forms import AmortizationForm
>
>   File "/home/modunique/proj/loan/amortization/forms.py", line 3, in
> <module>
>     from amortization.models import Amortization
>
> ImportError: No module named amortization.models
>
> Here's the relevant info in my apache conf:
>
>         <Location "/">
>                 SetHandler python-program
>                 PythonHandler django.core.handlers.modpython
>                 SetEnv DJANGO_SETTINGS_MODULE loan.settings
>                 PythonDebug On
>                 PythonPath "['/home/modunique/proj/'] + sys.path"
>                 PythonInterpreter loan
>         </Location>
>
> My project is located in /home/modunique/proj/loan, as suggested by
> part of the error above.  The offending import lines in the last two
> traceback errors look like:
>
> # /home/modunique/proj/loan/urls.py - line 7
> from loan.amortization.forms import AmortizationForm
>
> # /home/modunique/proj/loan/amortization/forms.py - line 3
> from amortization.models import Amortization
>
> Now if I change the import line (line 3) to from
> loan.amortization.models import Amortization", the error will
> disappear, but the next offending import in urls.py then fails.
> "forms.py" and "models.py" live in the same module, "amortization".
>
> According to my PYTHON_PATH, these things should be able to be found:
> ['/home/modunique/proj/', '/usr/local/python/lib/python2.5/site-
> packages/MySQL_python-1.2.2-py2.5-linux-i686.egg', '/usr/local/python/
> lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg', '/usr/local/
> python/lib/python25.zip', '/usr/local/python/lib/python2.5', '/usr/
> local/python/lib/python2.5/plat-linux2', '/usr/local/python/lib/
> python2.5/lib-tk', '/usr/local/python/lib/python2.5/lib-dynload', '/
> usr/local/python/lib/python2.5/site-packages', '/usr/local/python/lib/
> python2.5/site-packages/PIL']
>
> And like I said, what's strange is that if I run the development
> server @ my web host, it works fine!
>
> Keith
>
> On Aug 29, 12:57 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, 2008-08-28 at 21:41 -0700, lingrlongr wrote:
>
> > [...]
>
> > > Has something changed?  Nothing popped out at me on the Backwards-
> > > incompatible changes.
>
> > Nothing should have changed that caused this if your code was correct
> > earlier.
>
> > The best way to work out where the problem is simple to start bisecting
> > the subversion checkouts until you find the problem case. You know that
> > the current checkout, r8693 is bad. So, suppose r8600 is good. Then try
> > r8647 (halfway in between). If that's good, move forwards halfway again,
> > otherwise, move back halfway. Keep repeating and you'll eventually hit
> > the revision that caused the problem. Even if r8437 was the last good
> > revision (256 revisions ago), this will take a maximum of 8 tests to
> > find the version that changed things, so it's quite efficient.
>
> > Regards,
> > Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to