Python软件包通常托管在许多发行版的存储库中。在阅读了本教程的内容之后，特别是标题为“您真的要执行此操作”的部分，我避免使用pip，而是首选使用系统存储库，只是在不需要在存储库中安装软件包时才求助于pip。

但是，由于这是不一致的安装方法，因此仅使用pip会更好吗？对于在两个地方都可用的软件包，在系统自己的存储库上使用pip有什么好处/缺点？

我包含的链接指出

始终使用标准Debian / NeuroDebian软件包的优点是，这些软件包经过了仔细的测试，可以相互兼容。Debian软件包记录了与其他库的依赖关系，因此您将始终在安装过程中获得所需的库。

我用拱门。除apt以外的其他软件包管理系统是否属于这种情况？

我看到的用于pip以系统模块或用户模块的形式在系统上安装Python模块的最大缺点是，发行版的程序包管理系统不会了解它们。这意味着它们将不会用于需要它们的任何其他软件包，并且您将来可能要安装（或在升级后可能会开始使用其中一个模块）的任何软件包；然后，您将同时pip获得模块的-发行版和受版本管理的版本，这可能会引起问题（我最近遇到了另一个实例）。因此，您的问题最终成为一个全有或全无的命题：如果仅使用pip 对于Python模块，您将无法再使用发行版的软件包管理器来处理任何希望使用Python模块的事情...

您链接到的页面上给出的一般建议非常好：尝试尽可能使用发行版的软件包，仅pip用于未打包的模块，这样做时，请在用户设置中使用，而不要在系统中使用-宽。尽可能使用虚拟环境，尤其是在模块开发中。尤其是在Arch上，您不应遇到由较旧的模块引起的问题；即使在可能存在问题的发行版上，虚拟环境也很容易解决。

始终值得考虑的是，发行版的库和模块软件包主要是为在发行版中使用其他软件包而打包的。使用这些库和模块进行开发是一个很好的副作用，但这不是主要的用例。

TL; DR

• 使用pip（+的virtualenv）的东西（库，框架，也许开发工具）的项目（你开发）使用
• 将软件包管理器用于您使用的应用程序（作为最终用户）

开发依赖

如果您正在使用Python开发软件，则需要使用pip项目的所有依赖项，包括运行时依赖项，构建时依赖项或自动化测试和自动化合规性检查（线性，样式检查器，静态类型检查器）所需的东西。 ...）

有几个原因：

• 这使您可以使用virtualenv（直接或通过virtualenvwrapper或pipenv或其他方式）将不同项目的依赖项彼此分离，并将“在生产中”（作为用户）使用的python应用程序与任何外来的恶作剧（或甚至可能是不兼容的情况）。
• 这使您可以在requirements.txt（如果您的项目是应用程序）或setup.py（如果您的项目是库或框架）文件中跟踪项目的所有依赖项。可以将其与源代码一起检查到版本控制（例如Git）中，以便您始终知道代码的哪个版本依赖于依赖项的哪个版本。
• 即使其他开发人员不使用相同的Linux发行版，甚至不使用相同的操作系统，上述内容也可以使其他开发人员在您的项目上进行协作（如果使用的依赖项在Mac和Windows上也可用，或者碰巧使用了它们）。
• 您不希望操作系统软件包管理器的自动更新破坏您的代码。您应该更新依赖项，但是您应该有意识地并且有时选择这样做，以便可以准备修复代码或回滚更新。（这很容易，如果您在版本控制系统中跟踪完整的依赖项声明以及代码。）

如果您觉得需要将直接和间接依赖项分开（或区分可接受的依赖项版本范围和使用的实际版本，请参见“版本固定”），请查看pip工具和/或pipenv。这也将使您能够区分构建和测试依赖项。（构建和运行时依赖项之间的区别可能可以在中进行编码setup.py）

您使用的应用程序

对于您用作普通应用程序且恰好是用Python编写的内容，请使用操作系统的程序包管理器。这将确保它保持合理的最新状态，并与包管理器安装的其他内容兼容。大多数Linux发行版还会断言它们不发行任何恶意软件。

如果分发的默认软件包存储库中没有您需要的东西，则可以签出其他软件包存储库（例如，基于deb的发行版的启动板）或以pip任何方式使用。如果是后者，请使用--user而不是在系统范围内安装到用户的家中，这样您就不太可能中断Python安装。（对于您只需要暂时或很少需要的东西，甚至可以使用virtualenv。）

使用软件包管理器的另一个原因是，更新将自动应用，这对于安全性至关重要。考虑一下，如果使用的bean软件包Equifax已通过yum-cron-security自动更新，则可能未发生黑客攻击。

在我的个人开发框中，我使用Pip，在产品中我使用包。

如果我们正在谈论安装Python软件包以在您编写的代码中使用，请使用pip。

对于您正在处理的每个项目，创建一个虚拟环境，然后仅使用pip安装该项目所需的东西。这样，您就可以以一致的方式安装所有使用的库，它们包含在库中，不会干扰通过包管理器安装的任何库。

如果您打算发布任何python代码，通常会在项目中添加setup.py或requirements.txt，这将使pip自动获取其所有依赖项。使您可以轻松地为该项目创建或重新创建虚拟环境。

摘要

您要处理的模块分为三类：

1. 为OS软件包系统的所有用户安装的那些支持程序。（甚至可能包括人们使用Python进行编程时所​​使用的工具和库；请参见下文。）对于这些，您可以使用OS软件包，并pip在必要时安装到系统目录中。
2. 由特定用户安装的那些支持程序，仅供其自己使用，也用于其“日常”使用Python作为脚本语言的某些方面。对于这些，她使用pip --user，或许pyenv或pythonz，以及类似的工具和策略。
3. 那些支持特定应用程序的开发和使用。对于这些，您可以使用virtualenv（或类似的工具）。

这里的每个级别也可能会从上一个级别获得支持。例如，我们（2）中的用户可能依赖于通过OS软件包安装的Python解释器。

对此进行更详细的介绍：

系统程序和软件包

您想要“正常运行”的用Python编写的程序很简单：只需使用OS安装工具，然后将其随需携带即可；这与非Python程序没有什么不同。这可能会引入您的计算机上的用户可能开始依赖的Python工具/库（例如Python解释器本身！）。只要他们了解依赖关系，并且在理想情况下，知道在不提供依赖关系的主机上处理该依赖关系的替代方法，这就不是问题。

关于这种依赖关系的一个常见而简单的例子是我的一些以~/.local/bin/开头的个人脚本#!/usr/bin/env python。这些文件在RH / CentOS 7上可以正常运行（只要它们在Python 2下运行），并且大多数（但不是全部）Ubuntu安装都可以。它们不会在基本的Debian安装或Windows下进行。我不喜欢自己的个人环境非常依赖OS软件包（我在许多不同的OS上工作），因此我发现这样的事情是可以接受的。我在没有系统Python且无法安装Python的罕见主机上的备份计划是使用用户系统，如下所述。

使用系统python解释器的人通常也依赖于系统pip3。那就是我通常在系统依赖项上划清界限的地方。从此以后，virtualenv我都会处理自己。（例如，我的标准激活脚本依赖于任何pip3或者pip是路径，但下载自己的副本virtualenv，以引导它的创建虚拟环境。

就是说，在某些情况下，使更多的开发环境可用是完全合理的。您可能已经将Python接口插入了复杂的程序包（例如DBMS）中，您想在其中使用该程序的系统版本，并且您感觉最好也让系统选择用于与之对话的特定Python库代码。或者，您可能会为Python类部署具有基本开发环境的大量主机，并发现使用标准系统软件包进行自动化最容易。

用户“日常”程序和软件包

用户可能拥有不太适合虚拟环境的Python库或程序，因为他们想首先帮助创建虚拟环境（例如virtualenvwrapper），或者它们是您通常在命令行中使用的东西做非Python的工作。即使他们确实具有安装这些工具的系统版本的能力，也可能会更舒适地安装自己的工具（例如，因为他们希望使用该工具的最新版本及其依赖项）。

pip --user人们通常会为此使用什么，尽管某些依赖项（例如Python解释器本身）需要的更多。pyenv和pythonz对于构建个人解释器（无论是否安装~/.local/bin为默认解释器）非常有用，当然，如果有可用的dev库，则总是可以从源代码“手动”构建。

我尝试保留此处安装的最少的东西：virtualenvwrapper（因为我经常使用它）以及最新版本的pip。我试图避免在标准库之外或在Python 3上依赖于我编写的可在许多主机上使用的个人脚本。（尽管随着越来越多的这些个人脚本移至Python，我们将看到可以忍受多长时间）。

单独的应用程序开发和运行时环境

这是通常的virtualenv事情。对于开发，您几乎应该始终使用virtualenv来确保您没有在使用系统依赖项，或者经常使用多个来针对不同的Python版本进行测试。

这些虚拟环境也非常适合具有很多依赖项的应用程序，在这些应用程序中您要避免污染用户环境。例如，我通常设置一个virtualenv来运行Jupyter笔记本之类的东西。