[mod_python] sys.path problem

On 21/02/2008, AJ Coon <ajcoon at gmail.com> wrote:
> Hi Graham,
>
> I wonder if this is a useful piece of information.  I just noticed this in
> my logs:
>
> [Wed Feb 20 23:02:46 2008] [warn] mod_python (pid=29597,
> interpreter='InterpB'): Module directory listed in "sys.path". This may
> cause problems. Please check code. File being imported is
> "/var/handlerB/www/handlerB_root/ProjectModule.py".
>
> I'm not sure I understand what it's complaining about?

The new module importer underlaying import_module() and as also used
by Python*Handler tries to keep mod_python module importer path
separate from sys.path. This is because an overlap can cause problems
with modules load duplicate times. You must be explicitly adding the
document directory to sys.path in your script, which you shouldn't do.

Can you show first part of script where you set sys.path.

Graham

>
> -aj
>
>
>
>
> On Wed, Feb 20, 2008 at 9:41 PM, Graham Dumpleton
> <graham.dumpleton at gmail.com> wrote:
>
> >
> > On 21/02/2008, AJ Coon <ajcoon at gmail.com> wrote:
> >
> > > Hi Graham,
> > >
> > > I'm not using PythonPath anywhere, though my handlers both make
> > > sys.path.append() calls to add various library paths needed by each.
> > > Inconveniently, each of these handlers use different versions of some of
> the
> > > same libraries.  It's a bit of a mess, but this all worked fine on
> 3.1.3.
> > > Now that I upgraded to 3.3.1 (and changed nothing else), it's broken.
> > > Rolling back seems the obvious choice, but I think what I'm trying to do
> > > *is* do-able, no?
> >
> > As per the documentation I pointed out, try setting:
> >
> >  PythonOption mod_python.legacy.importer name
> >
> > this will restore the old module importer functionality. If it still
> > doesn't work, possibly something in Apache configuration causing
> > issues instead.
> >
> > In principle I can't see a problem with what you are trying to do,
> > although see comments below.
> >
> >
> > > As you requested, I have included my configuration below.  I'm just
> > > developing on a workstation and DNS is managed by /etc/hosts, hence the
> > > .localdomain host names.  Without further adieu:
> >
> > Do those names map to distinct IP addresses or the same?
> >
> > In Apache documentation it doesn't recommend that you use FQDN in
> > VirtualHost argument, but an IP address. Ie., in:
> >
> >
> http://httpd.apache.org/docs/2.2/mod/core.html#virtualhost
> >
> > It says:
> >
> >  """A fully qualified domain name for the IP address of the virtual
> > host (not recommended)"""
> >
> > The ServerName within the VirtualHost is what actually distinguishes
> > them if using name based lookup against the same IP address.
> >
> > If using IPs or names rather than just *:80 then NameVirtualHost isn't
> > required, but there have been cases where lack of NameVirtualHost in
> > Apache configuration has caused mod_python to somehow merge sites when
> > it shouldn't have been. Not know whether this is a bug in mod_python
> > or not as when people got it working by adding NameVirtualHost, they
> > were then interested in helping to debug the underlying problem.
> >
> >
> > > aj at aj-5150:~$ cat /var/handlerA/www/.htaccess
> > > PythonInterpreter InterpA
> > > Options -Indexes
> > >
> > > aj at aj-5150:~$ cat /var/handlerB/www/.htaccess
> > >  PythonInterpreter InterpB
> > > Options -Indexes
> >
> > Have you confirmed that the .htaccess files are in fact being
> > consulted. You can do this by introducing a syntax error in them. Ie.,
> > add a line consisting of 'CRAP'. If when making request you then get a
> > 500 error they are being consulted. The lack of an AllowOverride for
> > the directories suggests they may not even be getting consulted and so
> > the PythonInterpreter directives may not be getting applied. This may
> > be combining with NameVirtualHost issues to end up with stuff running
> > in same interpreter.
> >
> > You can work out which interpreter code is running in by printing out
> > 'apache.interpreter' from mod_python module.
> >
> > Graham
> >
>
>