Armin Ronacher 详细讨论了这个问题。从根本上说,Linux 发行版不够统一,您不能依赖特定库的存在来链接;甚至python库也可能不一致。
您可以为您正在使用的环境构建自己的轮子,并根据需要多次安装它们,这对于持续集成系统应该可以正常工作:
$ pip wheel pandas
Collecting pandas
Downloading pandas-0.18.1.tar.gz (7.3MB)
100% |████████████████████████████████| 7.3MB 131kB/s
...
Successfully built pandas
$ ls pandas*
pandas-0.18.1-cp35-cp35m-linux_x86_64.whl
$ pip install pandas-0.18.1-cp35-cp35m-linux_x86_64.whl
Processing ./pandas-0.18.1-cp35-cp35m-linux_x86_64.whl
...
Successfully installed pandas-0.18.1 python-dateutil-2.5.3 pytz-2016.4 six-1.10.0
请注意,numpy 确实在 pypi 上提供了 linux wheel 文件。查看内部(它们是简单的 zip 文件),我们可以看到它们捆绑了通常的 numpy 库,例如 lapack_lite 以及它们的依赖项(在本例中为 gfortran 和 openblas):
$ unzip -l numpy-1.11.0-cp35-cp35m-manylinux1_x86_64.whl | grep [.]so
...
38407360 2016-04-12 21:01 numpy/.libs/libopenblasp-r0-39a31c03.2.18.so
1017104 2016-04-12 21:01 numpy/.libs/libgfortran-ed201abd.so.3.0.0
108200 2016-04-12 21:01 numpy/linalg/lapack_lite.cpython-35m-x86_64-linux-gnu.so
...
相比之下,操作系统安装的 numpy 将 lapack_lite 链接到 /usr/lib/libblas,通过 debian 替代系统链接到优化的 libatlas,因此它应该具有更好的性能(未经测试)。
查看 lapack 链接,他们使用的是非常标准的库,因此它应该可以在许多 64 位 linux 系统上运行:
$ ldd lapack_lite.cpython-35m-x86_64-linux-gnu.so
linux-vdso.so.1 => (0x00007fffadf7a000)
libopenblasp-r0-39a31c03.2.18.so => /tmp/numpy/linalg/./../.libs/libopenblasp-r0-39a31c03.2.18.so (0x00007f5efb8bc000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5efb69e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5efb2d9000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5efafd3000)
libgfortran-ed201abd.so.3.0.0 => /tmp/numpy/linalg/./../.libs/libgfortran-ed201abd.so.3.0.0 (0x00007f5efacda000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5efe0d4000)
大概有人也可以自愿为 pandas 创建轮子,并让它们在不同版本的 python 中保持最新。请注意,pandas .so 文件链接到 libpython,但不知何故 numpy 避免这样做,尽管进行了 python 调用。
编辑 2016-05-25:添加了关于构建和安装轮子的说明。