所以，我想在 virtualenv 虚拟环境中运行 Python 3.4.x。我了解到第一步应该是构建 Python 3.4.x。
我是在 /usr/bin/Python3.4.x （我创建的文件夹）中执行此操作的，我在其中提取了 Python3.4.x 的内容。然后跑./configure，，make然后做了sudo make install。当该命令正在执行其工作时，我意识到我可能会因为覆盖核心 Debian 稳定 Python 而搞砸了。
在终端中运行的简单测试python表明我仍在使用Python 2.7.x，所以它似乎我很好，但我不知道。做类似的事情sudo make uninstall不是一个选择，因为我不认为 Python makefile 附带 make 的卸载规则。
做类似的事情sudo apt-get install --reinstall python也没有多大作用，让我感觉很安全，因为重新安装不需要覆盖任何文件？
无论如何，我不确定我刚才做了什么，我也不确定后果是什么。有人可以帮我理解吗？
我终于明白为什么我遵循的说明建议我使用 /opt/some_folder 前缀进行配置和制作，但我忽略了它......现在......是的。
答案1
覆盖默认Python版本的问题仍然存在。
正如在自述文件.rst，用于sudo make altinstall避免覆盖操作系统默认版本：
在 Unix 和 Mac 系统上，如果您打算使用相同的安装前缀（
--prefix配置脚本的参数）安装多个版本的 Python，则必须注意您的主要 Python 可执行文件不会被不同版本的安装覆盖。使用安装的所有文件和目录都make altinstall包含主要版本和次要版本，因此可以并存。make install还创建了${prefix}/bin/python3指的是${prefix}/bin/pythonX.Y。如果您打算使用相同的前缀安装多个版本，您必须决定哪个版本（如果有）是您的“主”版本。使用安装该版本make install。使用安装所有其他版本make altinstall。例如，如果您想安装 Python 2.7、3.5 和 3.6，其中 3.6 是主要版本，您将
make install在 3.6 构建目录中执行
答案2
首先：你不需要构建python来在virtualenv中运行它，你可以只使用系统提供的Python3.4.2：
virtualenv -p /usr/bin/python3.4 /path/to/your/venv
如果您覆盖了系统可执行文件和/或其库，您可能会遇到麻烦。测试这一点的方法之一是运行/usr/bin/lsb_release并查看它是否仍然有效。这是已经基于 python3 的实用程序之一（其他实用程序仍然基于 python2.7），并且由 调用apt-get，因此当它失败时，您就会遇到麻烦。如果可以的话，尝试重新安装 python3，只是为了确保覆盖编译和安装中的任何痕迹。
如果您获得了自己构建 python 所需的错误信息，那么分享一下也很好。因此，如果信息未被纠正，人们可能会回避该信息。