At 10:49 AM 3/13/2010 +0100, Lennart Regebro wrote:

On Sat, Mar 13, 2010 at 10:13, Lennart Regebro <regebro@gmail.com> wrote:

...

Well, I don't know if it does, but adding the makepath method from Pythons site.py seems to solve that problem anyway, and you get other errors. I don't have time to look into this very deeply, but Distribute/Setuptools seems to be a good test for cross-platform compatibility as it involves much magic. :)

Well, PyPy distutils.sysconfig does not have a customize_compiler, so it breaks there anyway.

But I realized something more: Could it be that in CPython, Pythons site.py is read in first and that context is retained when running a local site.py?

No. The site-patch code explicitly finds and loads the old module into the same namespace, in order to avoid the compatibility issues I mentioned previously. (i.e., some distros patch the site module to add custom site paths, despite the fact that the whole purpose of .pth files is to make it so you *don't* have to patch site.py to add such paths!)

Because now I again get the error that another method is missing (addsitedir) which does exist in Pythons site.py. It exists in PyPy's site.py as well, but not in distributes site.py.

Here are some possible ways you could get that behavior: 1. site-patch cannot load PyPy's built-in site module, and is instead finding an *empty* site.py on sys.path after it, OR 2. It is finding a valid site.py, but the standard import protocols (i.e., imp.find_module/load_module and path_importer_cache[modulename].load_module()) are not working correctly when called on an existing module. If you trace the execution of the site-patch to whichever load_module line is getting run, and print the value of the 'item' variable, you'll see what path entry the "original" site is being discovered in, and you'll then be able to tell which of the above possibilities applies. (Offhand, I'd guess that the import bug is perhaps a bit more likely; the reloading behavior of loaders and imp is a little on the obscure side and might not be sufficiently covered by the stdlib or PyPy tests. The likely failure is that some piece of code is returning a *new* module object, rather than updating the existing one as PEP 302 requires.)