[gobolinux-users] $pythonpath

[Jonas Karlsson]

On Wed, 28 Nov 2007 22:06:04 +0100, Carlo Calica <carlo at calica.com> wrote:

> On 11/28/07, Jonas Karlsson <jonka750 at student.liu.se> wrote:
>>
>> I've looked at the code in site.py and it has a 'if sitepath
>> in known_paths :' check, but only for appending the sitepath
>> to path. It still tries to process *.pth files in sitepath,
>> leading to the recursion. By indenting the following block,
>> handling the *.pth files this does not happen and the
>> addition to gobolinux.pth works. I've attached a diff with
>> the change. However this change changes the behaviour so
>> known paths can't be added as sitedirs, as it will be a
>> known path. Adding the 'import...' before the paths or just
>> not declaring the path beside the addsitedir(foo) works
>> around this issue. Maybe there's a better solution?
>>
>
> I'd like to step back and redefine the problem:
>
> Python does NOT read .pth files located in
> /S/L/L/python-2.5/site-packages.  Specifically, it reads gobolinux.pth
> in /P/Python/Current/lib/python-2.5/site-packages.  gobolinux.pth adds
> /S/L/L/python-2.5/site-packages to sys.path (might be wrong my python
> is weak) but then doesn't read any additional .pth files.  Basically
> reading .pth files doesn't recurse through a read .pth.
>
No, but the

import site; site.addsitepath('/S/L/L/python-2.5/site-packages',set())

adds /S/L/L/python-2.5/site-packages as a sitedir and makes site.py
parse all *.pth files there, which of course includes gobolinux.pth,
which adds /S/L/L/python-2.5/site-packages to the sitedir, which
includes gobolinux.pth, continue ad nauseam (or recursion limit is
reached, whichever comes first).

> Does that describe this bug?  Sorry I'm being explicit, I've been gone
> for awhile and don't want to waste time because I'm rusty.  Assuming
> yes.
>
> First we should find out if non-recursing .pth is a bug or a design
> choice.  The Python devs might have a very good reason to avoid it
> (similar to modutils not following symlinks)
>
The current implementation of site.py is recursive.

> If recursing is ok, Jonas patch may be a solution but it'll need a lot
> of testing.
>
As I said there's an issue with my patch, that known paths can't be
added as sitepaths, meaning that any *.pth file in that path wont be
handled.

> If recursing is not ok, we need to get python looking in /S/L/L
> instead of /P/Python directly.  I'd like to point at "def
> addsitepackages" in site.py.  Replacing "prefixes = [sys.prefix]" with
> "prefixes = ['/usr']" might have the desired effect .  This is
> probably a less drastic change.  Compiling python under rootless would
> be iffy.
>
I can confirm that the first path python ever looks at (with my setup)
is /Programs/Python/2.5.1/lib/python2.5/site-packages. There it finds
gobolinux.pth and continues from there. The problem is that even though
gobolinux.pth adds /S/L/L/python2.5/site-packages as a path, the *.pth
files (e.g. pygtk.pth) within that directory isn't handled, unless one
adds /S/L/L/python2.5/site-packages as a sitepath. Is that intended
behaviour?

> Anyone have a good test case for this?  HAL used to have
> hal-device-manager which used pygtk which tickled this bug but its not
> there anymore.
>
I just start the python prompt and try 'import gtk' to see if pygtk.pth
is parsed. Also running the 'import site' to find out if there's any
recursion.

-- 
/Jonas

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/