复刻Debian Wheezy旧系统后，mod_wsgi环境下Python跨路径导入同命名空间子包的故障排查求助

这问题确实有点 tricky——正常情况下Python不允许同一个命名空间包拆分到不同路径，但原系统居然能正常运行，咱们从mod_wsgi、Debian系统特性、Python命名空间机制这几个方向来梳理排查点：

1. 检查mod_wsgi的运行模式与路径配置 #

Debian Wheezy下的mod_wsgi默认可能用嵌入模式（和Apache主进程共用Python环境），而你复刻的系统如果配置了守护进程模式，可能环境差异导致问题：

• 对比原系统和复刻系统的Apache配置，看是否存在WSGIDaemonProcess、WSGIProcessGroup这类守护进程相关指令；
• 检查是否设置了WSGIPythonHome（指定Python安装路径）或WSGIPythonPath（添加额外Python路径），原系统可能通过这些指令调整了路径优先级，把/usr/lib/pymodules/python2.7提前；
• 可以在WSGI应用中打印sys.executable，确认两个系统中mod_wsgi使用的Python解释器是否一致。

2. 排查Debian系统对pymodules路径的特殊处理 #

Debian在旧版本中对/usr/lib/pymodules/python2.7有特殊的site-packages处理逻辑：

• 检查原系统的site.py文件（位于/usr/lib/python2.7/site.py）是否被修改过，比如有没有额外的代码把/usr/lib/pymodules/python2.7加入命名空间包的搜索路径；
• 遍历两个系统中/usr/lib/python2.7/dist-packages和/usr/lib/pymodules/python2.7下的.pth文件，看是否存在指向另一个repoze路径的配置（比如某个.pth里写了/usr/lib/pymodules/python2.7/repoze）；
• 在原系统的WSGI应用中执行import site; print(site.getsitepackages())，对比复刻系统的输出，确认系统级Python路径的处理差异。

3. 验证PEP 420前的命名空间包机制 #

在PEP 420（命名空间包的现代标准）之前，Python靠空__init__.py+pkg_resources实现跨路径的命名空间包：

• 检查原系统中setuptools的版本（执行import pkg_resources; print(pkg_resources.__version__)），旧版本的setuptools可能自动合并同命名空间的不同路径；
• 在原系统的WSGI应用中打印pkg_resources.get_distribution('repoze.who').location和pkg_resources.get_distribution('repoze.lru').location，看pkg_resources是否正确识别了两个子包的位置；
• 虚拟环境中无法导入repoze.who，可能是因为虚拟环境的setuptools配置未包含系统级的pymodules路径，而mod_wsgi使用的系统Python环境则通过pkg_resources处理了命名空间合并。

4. 检查Apache用户的文件权限 #

复刻系统可能存在权限问题，导致Apache运行的WSGI进程无法访问/usr/lib/pymodules/python2.7/repoze：

• 在WSGI应用中添加import os; print(os.listdir('/usr/lib/pymodules/python2.7/repoze'))，看是否能正常列出repoze.who的文件；
• 对比原系统和复刻系统中/usr/lib/pymodules/python2.7/repoze目录的权限（执行ls -ld /usr/lib/pymodules/python2.7/repoze），确保Apache用户（通常是www-data）有读取权限。

5. 对比mod_wsgi的编译与版本细节 #

原系统的mod_wsgi可能是Debian官方包（带特殊补丁），而复刻系统的mod_wsgi是手动编译的：

• 执行mod_wsgi -v对比两个系统的版本和编译参数；
• 检查Debian官方mod_wsgi包的补丁内容（可以通过apt-get source libapache2-mod-wsgi获取源码查看），看是否有处理跨路径命名空间包的特殊逻辑。

内容的提问来源于stack exchange，提问作者user2233709