Carlo Calica wrote: > On 11/28/07, Jonas Karlsson <[EMAIL PROTECTED]> 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. > > 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) > I already reported a bug about this. As result the documentation has been changed so that it is clear that python does not recurse in .pth files, it just parses the predefined dirs. Anyway some systems like os2, riscos and macos x have some extension in the official site.py so that additional directories are scanned for pth files (/Lib/site-packages, $HOME/Library/Python/2.5/site-packages).
> If recursing is ok, Jonas patch may be a solution but it'll need a lot > of testing. > > As I said, I already proposed that to python dev but the result was a clarification in docs. > 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. > > Changing site.py is a simple solution considered also by the python docs as last option. We could also consider just to patch site.py for the infinite recursion bug of addsitedir so that we can continue to use the function inside .pth files: addsitedir should track parsed pth files so that they are not parsed twice or more times. I reproduced the bug by symlinking gobopath.pth in /S/L/L/... > 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 think PyGObject may be used as test case (it requires gtk-2.0 to be in sys.path). Giambattista _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
