用了几年的 python 了，其实都知道 python的PATH包括：
* 当前目录
* 环境变量PYTHONPATH
* WINDOWS的注册表
* python安装目录下的lib和lib/site-packages
* 程序运行过程中sys.path中添加的
大多数时候装的第三方的模块都是装到它的lib/site-packages里去了，模块的名
字就是site-packages里的目录的名字。

但是还有一种情况，就是如果我有个模块在site-packages里，是一个目录的形式，名字叫 zwtest-0.1，这时候想要import这个模块的话，应该写成：

import zwtest-0.1

但是这样就很不爽了，如果出了 zwtest-0.2，连import都的改，有一办法就是在与zwtest-0.1相同目录里建立一个zwtest.pth的文件，里面内容是zwtest-0.1，这样python在查找模块的时候，会把zwtest.pth中的模块全部当成名为zwtest的模块，这时候 import zwtest 就和import zwtest-0.1效果一样了，就是升级了版本，只需要修改zwtest.pth就好了，而且也很好的解决了一个模块的多版本共存问题。并且，*.pth中是可以写多个模块的，一行写一个就行，很cool。

发现GNOME的东东版本的一致性好难控制，GNOME自己是由很多LIB组合起来
的，这些LIB互相依赖，如果其中一个LIB的版本错了，可能一些程序运行起来很正
常，而还有一些程序就会出问题。
今天在LINUX上装了 pyGTK 和wxPython2.6.2, 他们都是使用GTK的，装好后无
法运行我的程序，报一错误：undefined symbol:
FT_GlyphSlot_Embolden(/usr/lib/libcairo.so.2)，这样的东西见的太多了，通
常就是和库的版本有关。很恶的问题，记得wxPython在2.6.2版本之前装在比较新
的GNOME上就会有这个错误：undefined symbol: pango_x_get_context，只要
wxPython换到版本2.6.2就好了，这个问题曾经困扰了我好久。

先看看使用的SO的情况，用ldd /usr/lib/libcairo.so.2， 显示：
linux-gate.so.1 => (0xffffe000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40075000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4007d000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40176000)
libpng12.so.0 => /opt/gd/lib/libpng12.so.0 (0x40184000)
libglitz.so.1 => /usr/lib/libglitz.so.1 (0x401c3000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x401e7000)
libfreetype.so.6 => /opt/gd/lib/libfreetype.so.6 (0x40218000)
libz.so.1 => /lib/libz.so.1 (0x4027d000)
libm.so.6 => /lib/tls/libm.so.6 (0x40290000)
libc.so.6 => /lib/tls/libc.so.6 (0x402b6000)
libdl.so.2 => /lib/libdl.so.2 (0x403d5000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x403d9000)
/lib/ld-linux.so.2 (0x80000000)
果然有问题，libfreetype连错了，它用的是 /opt/gd/lib 下的。在/opt/gd/lib
下的是libfreetype.so.6.3.7， 而我的/usr/lib下的是 libfreetype.so.6.3.8，
版本不一样，就出了问题。至于为什么会连到那个so，是因为我的机器上装了一个
软件，它会安装一个gd，并且装到那个目录，还把/opt/gd/lib加到
了/etc/ld.so.conf中去。问题清楚了，去/etc/ld.so.conf中删除/opt/gd/lib
行，用root用户重新执行ldconfig重新配置了库信息就OK了，再次用
ldd /usr/lib/libcairo.so.2 看到的结果就正常了：
linux-gate.so.1 => (0xffffe000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40075000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4007d000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40176000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40184000)
libglitz.so.1 => /usr/lib/libglitz.so.1 (0x401c3000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x401e7000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40218000)
libz.so.1 => /lib/libz.so.1 (0x4027d000)
libm.so.6 => /lib/tls/libm.so.6 (0x40290000)
libc.so.6 => /lib/tls/libc.so.6 (0x402b6000)
libdl.so.2 => /lib/libdl.so.2 (0x403d5000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x403d9000)
/lib/ld-linux.so.2 (0x80000000)
其实像这样的问题，在 LINUX 下是经常出现的，而在Windows下是不容易出这样的
问题的。这个可能和两个系统的发展有关，windows下的绝大部分为商业软件，所
以基本上都会使用自己的库，没有什么开源的东西，不会像LINUX上的程序一样，
很多软件都组合了N多的开源东东。 有利也有弊，这个给LINUX系统带来很多不确
定性，造成一些依赖其他库太多的程序的稳定性不够，一是不能控制别人的程序的
质量，再者，版本的一致性问题到现在没有太好的解决办法，这很容易造成混乱。