☰

编译我自己的 python 破坏了系统脚本？

tag-icon • tag-icon debian python package-management dependencies crunchbang
编译我自己的 python 破坏了系统脚本？

（对于那些不熟悉的人来说，CrunchBang 基本上是一个预先配置的 Debian Squeeze。）

前段时间，我在编写一个脚本，想使用 2.7 版中引入的 Python 功能。由于我能从 Debian Squeeze 的 apt repo 获得的最新版本是 2.6.6.8，所以我决定下载最新源代码并自行构建。在自己处理依赖关系后，我终于开始工作，并完成了我的项目。

然而，从那时起，许多系统脚本就停止工作了。我注意到它们（现在损坏的脚本）都以#!/usr/bin/env python[1] 开头，并且依赖于 apt-get/synaptic 安装的一个或多个东西，但与 Python 2.6 相关联。我通过手动将标题更改为 修复了一些问题#!/usr/bin/python，但现在我开始怀疑

  1. 对于那些自己开发 Python 的人来说这很正常吗？
  2. 我是否以某种方式错误地编译/设置了 2.7？
  3. 期望使用 apt-get/synaptic 安装的软件包与安装它们的依赖项版本“锁定”在一起是否不合理？
  4. 我是否应该以某种方式重新配置/图形我的 $PATH 以便在该/usr文件之前找到该文件/usr/local？
  5. 我是否应该删除硬链接文件 /usr/local/bin/python 并让所有脚本都以 开头#!/usr/local/bin/python2.7？
  6. 我是否必须手动安装所有缺失的库等/usr/local？如果是这样，最好的方法是什么？
  7. 我应该向软件包维护者、项目本身，还是两者报告错误？

[1] 由于我的路径设置方式，调用的是我的/usr/local/bin/python（2.7），而不是系统的/usr/bin/python（2.6）

答案1

这是很正常的，大多数构建自己的 Python 环境的人都会使用类似虚拟环境来管理它们。替换系统提供的 Perl、Python 或 Ruby 几乎从来都不是一个好主意，这三种语言都为开发人员提供了管理自己的私有安装的方法（对于 Perl 有 PerlBrew，对于 Ruby 有 RVM）。

相关内容