如何轻松分发具有Python模块依赖关系的Python软件? Unix上Python软件包安装的挫折

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

我发现对于那些擅长Python打包(即使他们知道如何编写Python)的Unix精明用户来说,安装像我这样的软件包,即使使用本应该易于使用的软件包pipe理器,也是极其令人沮丧和几乎不可能的。 我想知道是否有人可以提供这个痛苦过程的替代scheme,或者如果我的经验仅仅反映了当前Python封装和分发的困境。

假设用户将你的软件包下载到他们的系统上。 大多数人会尝试安装它“天真”,使用像这样的东西:

$ python setup.py install 

因为如果你的谷歌说明安装Python包,通常会出现这种情况。 这对绝大多数用户来说是失败的,因为大多数用户在他们的Unix / Linux服务器上没有root权限。 随着更多的search,他们会发现“ – 前缀”选项,并尝试:

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

由于用户没有意识到Python打包的复杂性,他们会select一个任意目录作为--prefix的参数,例如"~/software/mypackage/" 。 它不会是一个干净的pipe理目录,其他所有Python包都驻留在这里,因为大多数用户都不知道这些细节。 如果他们安装另一个软件包“myotherpackage”,他们可能会通过它"~/software/myotherpackage" ,你可以想象这将导致PYTHONPATH和其他并发症的黑客入侵。

继续安装过程,使用"--prefix"调用"setup.py install"也将失败,一旦用户尝试使用该软件包,即使它似乎已经被正确安装,因为其中一个依赖关系可能会丢失(例如pandas,scipy或numpy),并且不使用包pipe理器。 他们将尝试单独安装这些软件包。 即使成功,由于给予"--prefix"的非标准目录, PYTHONPATH包将不可避免地在PYTHONPATH ,患者用户将会修改其PYTHONPATH来获取依赖关系。

在这个阶段,一位Python精明的朋友可能会告诉用户,他们应该使用像"easy_install"的主streampipe理器的软件包pipe理器来安装软件,并且依赖关系被处理。 安装"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没有 – 用户选项,其中有明确的网页在线描述的选项。 他们可能会尝试将easy_install升级到最新版本,并发现它仍然失败。

如果他们继续并咨询Python包装专家,他们会发现easy_install两个版本 ,都称为“ easy_install" ,以最大限度地混淆,但一部分“分发”和另一部分“setuptools”。 恰好是只有"distribute""easy_install"支持"--user" ,绝大多数服务器/系统pipe理员都安装了"setuptools"easy_install ,所以本地安装是不可能的。 请记住,对于不是Python包pipe理专家的人来说, "distribute""setuptools"之间的区别是没有意义的,也很难理解。

在这一点上,即使是那些试图安装我的软件包的最坚定,精明和耐心的用户,我也会损失90% 他们想要安装一个碰巧用Python编写的软件,而不是成为最先进的Python软件包分发的专家,这太复杂了。 他们会放弃,在浪费的时候感到沮丧。

继续使用并请求更多Python专家的极less数用户将被告知他们应该使用pip/virtualenv而不是easy_install 。 安装pipvirtualenv ,弄清楚这些工具是如何工作的,以及它们与传统的"python setup.py""easy_install"调用有什么不同,这本身就是耗时和困难的,而且对于那些只想要安装一个简单的Python软件并使用它。 即使那些追求这条道路的人也会困惑,不pipe是用easy_install还是setup.py install --prefix安装的任何依赖关系对于pip/virtualenv是否仍然可用,或者是否需要从头开始重新安装。

如果有一个或多个软件包依赖于安装不同于默认版本的Python版本,则会加剧此问题。 确保你的Python包pipe理者使用你想要的Python版本,以及所需的依赖关系被安装在相关的Python 2.x目录而不是Python 2.y中的困难将会使用户感到无限的沮丧,肯定会放弃在这个阶段。

有没有更简单的方法来安装Python软件,不需要用户深入研究Python包,path和位置的所有这些技术细节? 例如,我不是一个大的Java用户,但偶尔也会使用一些Java工具,而且不记得曾经担心安装的Java软件的X和Y依赖关系,而且我也不知道Java包pipe理作品(我很高兴我没有 – 我只是想用一个恰好用Java编写的工具)。我的回忆是,如果你下载一个jar子,你只是得到它,它倾向于工作。

有没有相当于Python? 一种分发软件的方式,不依赖于用户不得不追逐所有这些依赖和版本? 一种可能将所有相关的软件包编译成独立的,只能被下载和用作二进制文件的方法?

我想强调的是,即使向精明的Unix用户分发一个软件包的狭隘目标,也会发生这种沮丧,这使得问题变得更简单,不用担心跨平台问题等。我假定用户是Unix精通的,甚至可能知道Python,但是对于Python包装的来龙去脉以及不同包pipe理者的各种内部复杂化/竞争,我们并不知情(也不想知道)。 这个问题的一个令人不安的特点是,即使所有的Python包依赖是众所周知的,写得很好的Pypi可用软件包,像Pandas,Scipy和Numpy,它也会发生。 这并不是说我依赖一些模糊的依赖关系,而是没有正确构build的包,而是使用了许多可能依赖的最主stream的包。

任何帮助或build议,将不胜感激。 我认为Python是一个伟大的语言库,但是我发现实际上不可能把我编写的软件(一旦它存在依赖关系)以一种易于本地安装和运行的方式分发。 我想澄清一下,我正在编写的软件不是用于编程使用的Python库,而是具有用户作为单独程序运行的可执行脚本的软件。 谢谢。

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

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

该软件包已编译,所有依赖项都在本地安装,这意味着安装软件包的用户甚至不需要root权限,这是一个附加function。 脚本(通常)放在./bin下,用户可以在那之后执行它们。 zc.buildout使用setuptools与PyPI进行交互,因此您所期望的所有function都可以zc.buildout使用。

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

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

就目前而言,easy_install两个竞争版本的问题已经解决,竞争的fork“distribute”被合并到了setuptools的主要开发线中。

关于跨平台发行和安装Python软件的最佳可用build议在这里被捕获: https : //packaging.python.org/