At 05:14 PM 2/9/2006 -0600, Ian Bicking wrote: >Phillip J. Eby wrote: >>This is really good news, however. It appears to mean that slapping a >>copy of my hacked 'site.py' (i.e., the one that honors .pth files along >>PYTHONPATH) into the easy_install target directory would make >>PYTHONPATH-based installs essentially DWIMmish. To complete the >>illusion, I'd need to add some code to script wrappers to process the >>setuptools.pth file in the script directory if pkg_resources can't be >>otherwise imported. > >I think I kind of understand, but I'm not sure I have (or remember) the >full context behind this proposal. What hacked site.py are we talking about?
I meant the one that's bundled inside the setuptools .egg right now, but the lib64 issue has now made me a bit more wary. I'm trying to design an alternate hacked site.py that uses the system site.py, so that if the distro uses a patched site.py, it'll still work correctly. My thoughts for the new site.py are that it'll just do two things: 1. find the stdlib on sys.path (by skipping all the PYTHONPATH entries) and use sneaky import tricks to replace itself with the "real" site module. 2. call addsitedir() on all the directories in PYTHONPATH, then scoot all the added directories to just *before* the stdlib in sys.path (i.e., just after the PYTHONPATH entries) I've painstakingly hacked together some code that accomplishes #1, and am now trying to figure out a sane way to do #2. The big problem is that 'site' munges the bleeding hell out of sys.path, such that there are no guarantees about the position, case, etc. of entries in it after, relative to before. It'd be easiest to just throw all the new entries to the head of the path, but that's not an especially compatible way to do it, relative to what I'd like to see the Python 2.5 site module do. I think what I'm going to do for now is find the first "system" path entry (i.e. the first one after the PYTHONPATH entries. (Side note: one of the other really tricky bits in all this is that Python 2.3 and 2.4 on different platforms appear to treat empty PYTHONPATH differently from each other and from an unspecified PYTHONPATH, and the initial value of sys.path can vary in um, interesting ways as a result. Ugh.) > What exactly will the generated scripts look like in this model? The same as now, but with a try/except around the pkg_resources import, with the except: branch looking for a setuptools.pth file in the script directory. This should only be needed to insure that "-mad" (i.e. self-contained full app installs to non-PYTHONPATH dirs) will work on non-Windows platforms. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
