在OS python升级之后,virtualenv python在简单任务中出现"未定义的符号:_PyLong_AsInt"错误

Question

我有一个基于python-2.7.3的长期工作virtualenv.在接受推荐的平台操作系统(Ubuntu)更新(其中许多其他更改)使python达到2.7.6之后,virtualenv中的python已经开始在基本上所有非平凡任务上出错,堆栈结束如下:

ImportError: /home/myusername/ENVS/myvenv/lib/python2.7/lib-dynload/_io.so: undefined symbol: _PyLong_AsInt

即使pip freeze失败了这样的错误 - 甚至无法在破碎的virtualenv中获得已安装包的准确库存(可能重新安装到新的工作virtualenv)!

不应该保护virtualenv免受这种外部升级？或者至少在2.7.x系列中？

Answer 1

你可以干脆做

cp /usr/bin/python2 /path/to/my-virtualenv/bin/python2

要么

cp /usr/bin/python3 /path/to/my-virtualenv/bin/python3

Answer 2

virtualenv 正在引用外部安装 - 在这种情况下，路径实际上是已更新的 的myvenv/lib/python2.7/lib-dynload软链接。/usr/lib/python2.7/lib-dynload那么回滚到 2.7.3 可能可行吗？

尝试从 python.org 下载 2.7.3 源代码，并使用通常的咒语构建/安装（即使知道这会破坏系统首选的 python，这是我使用全系统 VM 快照时可能承担的风险）：

cd Python-2.7.3/
./configure 
make
sudo make install

仍然不走运：同样的错误，即使软链接现在指向基于 2.7.3 的资源。但是如何将系统 /usr/bin/python-2.7 复制到 virtualenv 中呢？（我不愿意使用不同的版本，但在这一点上，为什么不呢？）

这解决了问题。virtualenv 现在正在工作，至少允许对“pip freeze”库存进行一些测试和提取。当然，依赖于 2.7.6 的外部东西现在可能会被破坏。

而且，将系统 2.7.6 python 可执行文件拉入 virtualenv 来替换其损坏的版本可能就足够了，而且是安全的。（不知道——其他答案/资源意味着在 virtualenv 中升级 python 时会出现问题，除非之后重新安装所有包，尽管它们主要解决像 2.5 -> 2.6 这样的非点修订。）