有关安装工具和替代方案的问题

Question

我最近在互联网上看到了很多对 setuptools 的攻击。 最近，我阅读了 James Bennett 的关于包装的文章，了解了原因没有人应该使用 setuptools。 从我在 Freenode 上使用 #python 的那段时间起，我就知道那里有一些人绝对讨厌它。 我会把自己算在其中，但我确实在使用它。

我已经在足够多的项目中使用了 setuptools，以意识到它的缺陷，并且我更喜欢更好的东西。 我不太喜欢鸡蛋的形式及其部署方式。 对于安装工具的所有问题，我还没有找到更好的替代方案。

我对 pip 这样的工具的理解是，它是一个 easy_install 的替代品（而不是 setuptools）。 事实上，pip 使用了一些 setuptools 组件，对吗？

我的大多数包都使用 setuptools-aware setup.py，它声明了所有依赖项。 当它们准备好后，我将构建 sdist、bdist 和 bdist_egg，并将它们上传到 pypi。

如果我想改用 pip，我需要进行哪些更改才能摆脱 easy_install 依赖项？ 依赖项在哪里声明？ 我猜我需要摆脱使用 Egg 格式，而只提供源代码发行版。 如果是这样，我如何生成 Egg-info 目录？ 或者我是否需要这样做？

这将如何改变我对 virtualenv 的使用？ virtualenv 不是使用 easy_install 来管理环境吗？

这将如何改变我对 setuptools 提供的“develop”命令的使用？ 我不应该使用它吗？ 还有什么选择呢？

我基本上是想了解我的开发工作流程是什么样子的。

在有人提出建议之前，我并不是在寻找依赖于操作系统的解决方案。 我主要关心 debian linux，但 deb 软件包不是一个选择，原因 Ian Bicking 概述了 此处。

Answer 1

pip 使用Setuptools，并且不需要对包进行任何更改。 它实际上使用Setuptools安装软件包，使用：

python -c 'import setuptools; __file__="setup.py"; execfile(__file__)' \
    install \
    --single-version-externally-managed

因为它使用该选项（--single-version-externally-management），所以它不会将eggs安装为zip文件，不支持同时安装多个eggs软件的版本，并且软件包是平面安装的（例如，如果您仅使用 distutils，则 python setup.py install 可以工作）。 Egg 元数据仍然安装。 pip 还像 easy_install 一样，下载并安装包的所有要求。

此外您还可以使用需求文件来添加应批量安装的其他软件包，并使版本要求更加准确（无需将这些确切的要求放入您的 setup.py< /代码> 文件）。 但如果您不创建需求文件，那么您将像 easy_install 一样使用它。

对于您的 install_requires，我不建议您进行任何更改，除非您一直在尝试创建已知良好的非常精确的要求。 我认为在 setup.py 文件中关于版本的准确程度是有限的，因为您无法真正知道新库的未来兼容性会是什么样子，而且我也不知道建议您尝试预测这一点。 需求文件是放置保守版本需求的替代位置。

您仍然可以使用python setup.pydevelop，事实上，如果您执行pip install -e svn+http://mysite/svn/Project/trunk#egg=Project > 它将检查它（进入src/project）并在其上运行setup.pydevelop。 所以这个工作流程实际上并没有什么不同。

如果您详细地运行 pip（例如 pip install -vv），您将看到许多正在运行的命令，并且您可能会识别其中的大多数命令。

Answer 2

对于初学者来说，pip 确实很新。 新的、不完整的并且基本上未经现实世界的测试。

它显示出巨大的前景，但直到它可以完成 easy_install/setuptools 可以做的所有事情之前，它不太可能大范围流行，尤其是在公司中。

Easy_install/setuptools 又大又复杂——这冒犯了很多人。 不幸的是，这种复杂性有一个很好的理由，那就是它可以满足大量不同的用例。 我自己的支持大量（> 300）桌面用户，以及一个类似大小的网格和经常更新的应用程序。 我们可以通过允许每个用户从源代码安装来做到这一点的想法是可笑的——鸡蛋已经证明自己是分发我的项目的可靠方式。

我的建议：学习使用 setuptools - 这真的是一件很棒的事情。 大多数讨厌它的人并不理解它，或者根本不具备作为全功能分发系统的用例。

:-)

Answer 3

我是在 2014 年 4 月写这篇文章的。请注意有关 Python 打包、分发或安装的任何文章的日期。 看起来，在过去三年里，派系之争有所减少，实施有所改善，PEP 标准化和战线统一。

例如，Python 打包权威是“一个维护Python打包中许多相关项目的工作组”。

python.org Python 打包用户指南 有 工具推荐 和 Python 打包的未来 部分。

distribute 是 setuptools 的一个分支，于 2013 年 6 月重新合并。该指南称，“使用 setuptools 定义项目并创建源代码发行版。”

从 PEP 453 和 Python 3.4 开始，该指南建议“使用 pip 从 PyPI 安装 Python 包”，并且 pip 包含在 Python 3.4 中，并由 pip 安装在 virtualenvs 中code>pyvenv，也包含在内。 您可能会发现 PEP 453“基本原理”部分很有趣。

指南中还提到了一些新的工具，包括 wheel 和 buildout。

我很高兴阅读了以下两本技术/半政治历史。

作者：Martijn Faassen，2009 年：Python 打包的历史。

Armin Ronacher 在 2013 年 6 月发表的文章（标题并不严肃）： Python 封装：仇恨、仇恨、仇恨无处不在。