如何轻松分发具有Python模块依赖性的Python软件？ Unix上的Python包安装令人沮丧

Question

我的目标是分发一个Python包，其中包含其他几个广泛使用的Python包作为依赖项。 我的包依赖于编写良好的Pypi索引包，如pandas，scipy和numpy，并在setup.py中指定需要某些版本或更高版本，例如“numpy> = 1.5”。

我发现，对于那些不是 Python打包专家的Unix精明用户（即使他们知道如何编写Python）来安装像我这样的软件包，即使在使用易于使用的软件包管理器时，这也是非常令人沮丧的。 我想知道是否有一个替代这个痛苦的过程，有人可以提供，或者如果我的经验只是反映了Python包装和分发的当前状态非常困难。

假设用户将您的包下载到他们的系统上。 大多数人会试图“天真地”安装它，使用类似的东西：

$ python setup.py install

因为如果你有关于安装Python软件包的google说明，通常会出现这种情况。 这对绝大多数用户来说都是失败的，因为大多数用户的Unix / Linux服务器上没有超级用户访问权限。 通过更多搜索，他们将发现“--prefix”选项并尝试：

$ python setup.py install --prefix=/some/local/dir

由于用户不知道Python包装的复杂性，他们会选择一个任意目录作为--prefix的参数，例如"~/software/mypackage/" 。 它不会是所有其他Python包所在的干净策划目录，因为大多数用户都不知道这些细节。 如果他们安装另一个包“myotherpackage”，他们可能会通过它"~/software/myotherpackage" ，你可以想象这将导致令人沮丧的PYTHONPATH和其他并发症的黑客入侵。

继续安装过程，一旦用户尝试使用该软件包， "setup.py install"对"--prefix"的调用也将失败，即使它似乎已正确安装，因为其中一个依赖项可能会丢失（例如pandas，scipy或numpy）并且不使用包管理器。 他们会尝试单独安装这些软件包。 即使成功，由于给予"--prefix"的非标准目录，包将不可避免地处于PYTHONPATH ，并且患者用户将涉及修改其PYTHONPATH以使依赖性可见。

在这个阶段，Python精明的朋友可能会告诉用户他们应该使用像主流经理"easy_install"这样的包管理器来安装软件并依赖于依赖关系。 安装"easy_install" ，可能会遇到困难，他们会尝试：

$ easy_install setup.py 

这也将失败，因为用户通常无权在生产Unix服务器上全局安装软件。 通过阅读更多，他们将了解"--user"选项，并尝试：

$ easy_install setup.py --user 

他们会得到错误：

usage: easy_install [options] requirement_or_url ...
   or: easy_install --help

error: option --user not recognized

他们将非常困惑为什么他们的easy_install没有--user选项，其中有明确的在线页面描述该选项。 他们可能会尝试将easy_install升级到最新版本并发现它仍然失败。

如果他们继续并咨询Python打包专家，他们会发现有两个版本的easy_install ，都名为“ easy_install" ，以便最大限度地混淆，但是“分发”的一部分和“setuptools”的另一部分。 碰巧只有"distribute"的"easy_install"支持"--user" ，而绝大多数服务器/系统管理员都安装了"setuptools"的easy_install ，因此无法进行本地安装。 请记住，对于那些不是Python包管理专家的人来说， "distribute"和"setuptools"之间的区别是没有意义的，也很难理解。

在这一点上，即使是那些试图安装我的软件包的最坚定，最精明和耐心的用户，我也会失去90％ - 这是理所当然的！ 他们想安装一个碰巧用Python编写的软件，而不是成为最先进的Python软件包发行版的专家，这太混乱和复杂了。 他们会在浪费的时候放弃并沮丧。

继续询问更多Python专家的少数用户将被告知他们应该使用pip/virtualenv而不是easy_install 。 安装pip和virtualenv并弄清楚这些工具是如何工作的，以及它们与传统的"python setup.py"或"easy_install"调用有何不同本身是耗时且困难的，并且再一次要求来自想要的用户安装一个简单的Python软件并使用它。 即使那些追求这条道路的人也会对使用easy_install或setup.py install --prefix安装的依赖关系是否仍然可以与pip/virtualenv一起使用，或者是否需要从头重新安装所有东西感到困惑。

如果一个或多个相关软件包依赖于安装不同版本的Python而不是默认版本，则会加剧此问题。 难以确保您的Python包管理器使用您想要的Python版本，并且所需的依赖项安装在相关的Python 2.x目录中，而不是Python 2.y，对于用户来说，这将是无穷无尽的沮丧肯定会在那个阶段放弃。

有没有更简单的方法来安装Python软件，不需要用户深入研究Python包，路径和位置的所有这些技术细节？ 例如，我不是一个大的Java用户，但我偶尔会使用一些Java工具，并且不记得曾经不必担心我正在安装的Java软件的X和Y依赖性，而且我不知道Java包是怎么回事管理工作（我很高兴我没有 - 我只是想使用一个恰好用Java编写的工具。）我的回忆是，如果你下载一个Jar，你就可以得到它并且它可以工作。

是否有Python的等价物？ 一种以不依赖于用户必须追逐所有这些依赖关系和版本的方式分发软件的方法？ 一种方法可能将所有相关的包编译成自包含的东西，可以下载并用作二进制文件？

我想强调的是，即使是向精明的Unix用户分发软件包的狭隘目标，这种挫败感也会发生，这使得问题更简单，不用担心跨平台问题等等。我认为用户是Unix精明的，甚至可能知道Python，但只是不知道（并且不想让人知道）Python包装的细节和不同包装管理器的无数内部复杂/竞争。 这个问题的一个令人不安的特点是，即使所有的Python包依赖都是众所周知的，编写良好且维护良好的Pypi可用软件包（如Pandas，Scipy和Numpy），它也会发生。 这并不像我依赖于一些不正确形成包的模糊依赖：相反，我使用的是许多人可能依赖的最主流的包。

任何有关此的帮助或建议将不胜感激。 我认为Python是一个很棒的语言，有很好的库，但我发现几乎不可能以一种易于人们在本地安装并运行的方式分发我在其中编写的软件（一旦它具有依赖性）。 我想澄清的是，我正在编写的软件不是用于程序化使用的Python库，而是具有用户作为单独程序运行的可执行脚本的软件。 谢谢。

Answer 1

我们还开发了依赖于numpy，scipy和其他PyPI包的软件项目。 现在，用于管理远程安装的最佳工具是zc.buildout 。 它非常易于使用。 您从他们的网站下载引导脚本并将其与您的包一起分发。 您编写了一个“本地部署”文件，通常称为buildout.cfg ，它解释了如何在本地安装软件包。 你buildout.cfg携带bootstrap.py文件和buildout.cfg - 我们使用python包中的MANIFEST.in文件强制嵌入这两个文件，其中包含由PyPI分发的zip或tar球。 当用户解压缩它时，它应该执行两个命令：

$ python bootstrap.py # this will download zc.buildout and setuptools
$ ./bin/buildout # this will build and **locally** install your package + deps

编译包并且所有依赖项都在本地安装，这意味着安装包的用户甚至不需要root权限，这是一项附加功能。 脚本（通常）放在./bin下，因此用户可以在此之后执行它们。 zc.buildout使用setuptools与PyPI进行交互，因此你期望的一切都是开箱即用的。

如果所有功能都不够，你可以很容易地扩展zc.buildout - 你创建所谓的“配方”，可以帮助用户创建额外的配置文件，从网上下载其他东西或实例化自定义程序。 zc.buildout网站包含一个视频教程，详细解释了如何使用buildout以及如何扩展它。 我们的项目Bob广泛使用buildout来分发用于科学用途的包。 如果您愿意，请访问以下页面 ，其中包含有关如何设置python包的开发人员的详细说明，以便其他人可以使用zc.buildout在本地构建和安装它们。

Answer 2

我们目前正在努力让用户更容易开始以独立于平台的方式安装Python软件（特别参见https://python-packaging-user-guide.readthedocs.org/en/latest/future.html和http://www.python.org/dev/peps/pep-0453/ ）

目前，两个相互竞争的easy_install版本的问题已经解决，竞争的分支“分发”被合并到setuptools主线的开发中。

有关跨平台分发和安装Python软件的最新建议如下： https ： //packaging.python.org/