On Tue, Apr 19, 2005 at 03:00:49PM +0200, M.-A. Lemburg wrote: > Jeremy Sanders wrote: > > On Mon, 18 Apr 2005, M.-A. Lemburg wrote: > > > >> Why not os.exists() ? > > s/os.exists/os.path.exists > > > Probably better :-) > > > >> Wouldn't checking for the lib file in either lib64 > >> or lib be more reliable ? > > > > That might be better. I don't know whether it's possible that more than > > one python is installed (one in /lib and one in /lib64). > > That would certainly be possible. > > >> Hmm, this is not entirely correct, e.g. Suse 9.2 puts > >> the site-packages directory and all the other .py files > >> into /usr/lib64 as well - not only the platforma dependent > >> files. > >> > >> Not sure what other AMD64 distros do... but I have a feeling > >> the /lib/ should *always* be replaced by unix_platlib. > > > > > > It looks like RedHat/Fedora patch their package to only put the platform > > specific files in /lib64 (that's how I made my patch). > > > > Perhaps this isn't a good idea to do then :-( I wonder whether it would > > be possible for distribution to set these values somewhere. Couldn't > > python have a sys function to return its Makefile?
Fedora does it this way because of .noarch.rpm packages. Pure python libraries should run just fine both on x86 and x86_64, and since it's /usr/lib on x86, x86_64 has to know about /usr/lib too (which is sort of confusing). I believe you can get away without patching anything, if you do: from distutils import sysconfig print sysconfig.get_python_lib() to which you either pass plat_specific = 0 or 1. This will properly parse the right Makefile (which is probably what you ended up doing). Misa _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
