Python打包概述¶
作为一种通用的编程语言，python被设计成可以在很多方面使用。你可以建立网站、工业机器人或游戏供你的朋友玩，更重要的是，所有这些都使用相同的核心技术。
python的灵活性是每个python项目的第一步必须考虑项目的受众和项目将运行的相应环境的原因。在编写代码之前考虑打包可能看起来很奇怪，但这个过程对于避免将来的头痛确实是一个奇迹。
这个概述提供了一个通用的决策树，用于解释Python过多的打包选项。继续阅读，为下一个项目选择最佳技术。
目录
关于部署的思考¶
存在要安装的程序包（或 已部署 ，所以在打包任何东西之前，您需要对下面的部署问题有一些答案：
您的软件的用户是谁？您的软件是由其他软件开发人员、数据中心的运营人员或不太懂软件的团队安装的吗？
您的软件是要在服务器、台式机、移动客户端（电话、平板电脑等）上运行，还是要嵌入专用设备中？
您的软件是单独安装的，还是批量安装的？
打包是关于目标环境和部署经验的。以上问题有很多答案，每种情况的组合都有自己的解决方案。有了这些信息，下面的概述将指导您了解最适合您的项目的打包技术。
打包python库和工具¶
你可能听说过皮皮， setup.py 和 wheel 文件夹。这些只是Python生态系统为向开发人员分发Python代码而提供的一些工具，您可以在 包装配送项目 .
以下打包方法适用于技术受众在开发环境中使用的库和工具。如果您正在寻找为非技术受众和/或生产设置打包python的方法，请跳到 打包python应用程序 .
python模块¶
一个python文件，只要它只依赖于标准库，就可以重新发布和重用。您还需要确保它是为正确版本的Python编写的，并且只依赖于标准库。
这对于在拥有兼容的Python版本（如通过电子邮件、stackoverflow或github-gists）的人之间共享简单的脚本和代码片段非常有用。甚至还有一些完整的python库提供了这个选项，例如 bottle.py 和 boltons .
但是，对于由多个文件组成、需要额外的库或需要特定版本的Python的项目，此模式无法进行扩展，因此下面的选项如下。
python源分布¶
如果您的代码由多个python文件组成，那么它通常被组织成一个目录结构。包含python文件的任何目录都可以包含 import package .
因为包由多个文件组成，所以很难分发。大多数协议一次只支持传输一个文件（您上次单击链接并下载多个文件是什么时候？）。传输不完整更容易，而且在目的地更难保证代码完整性。
只要您的代码只包含纯Python代码，并且您知道部署环境支持您的Python版本，那么您就可以使用Python的本机打包工具创建一个 来源 distribution package 或 s列表 简而言之。
Python 的 SDISTS 是压缩档案 (.tar.gz 文件）包含一个或多个包或模块。如果您的代码是纯Python，并且您只依赖于其他的Python包，那么您可以 go here to learn more .
如果您依赖任何非python代码或非python包（例如 libxml2 如果是 lxml 或blas库 numpy ，您将需要使用下一节中详细介绍的格式，这对于纯Python库也有许多优势。
注解
python和pypi支持多个发行版，提供同一包的不同实现。例如，未经维护但具有开创性的 PIL distribution 提供PIL包，也提供PIL包 Pillow 积极维护的PIL分支！
这种python包装的超级能力可以让枕头成为pil的替代品，只需改变项目的 install_requires 或 requirements.txt .
python二进制分布¶
很多Python的实际能力来自于它与软件生态系统的集成能力，特别是以C、C++、FORTRAN、RISC和其他语言编写的库。
并非所有开发人员都有正确的工具或经验来构建用这些编译语言编写的组件，所以Python创建了 wheel 是一种包格式，旨在向库提供已编译的工件。实际上，python的包安装程序， pip ，总是喜欢使用轮子，因为安装总是更快，所以即使纯Python包也能更好地使用轮子。
当二进制分布与源分布匹配时，它们是最好的。即使您不为每个操作系统上传代码轮盘，通过上传sdist，您仍然可以让其他平台的用户自己构建它。默认同时发布sdist和wheel存档， 除非 您正在为一个非常具体的用例创建工件，您知道接收者只需要其中一个。
python和pypi可以轻松地将轮子和sdist一起上载。只要跟着 打包python项目 辅导的。
python推荐的内置库和工具打包技术。摘自 The Packaging Gradient (2017) .¶
打包python应用程序¶
到目前为止，我们只讨论了Python的本地分发工具。根据我们的介绍，您可以正确地推断这些内置方法仅针对具有Python的环境，以及了解如何安装Python包的观众。
由于操作系统、配置和人员的多样性，这种假设只有在面向开发人员受众时才是安全的。
Python的本机打包主要是为在开发人员之间分发可重用代码（称为库）而构建的。你可以背着 工具 或者开发人员的基本应用程序，在python的库打包之上，使用类似的技术 setuptools entry_points .
库是构建基块，而不是完整的应用程序。对于分发应用程序，有一个全新的技术世界。
接下来的几节将根据这些应用程序打包选项对目标环境的依赖性来组织它们，以便您可以为项目选择正确的打包选项。
取决于框架¶
一些类型的python应用程序，如网站后端和其他网络服务，非常常见，它们有足够的框架来支持它们的开发和打包。其他类型的应用程序，如动态Web前端和移动客户机，都非常复杂，足以使框架变得不仅仅是一种便利。
在所有这些情况下，从框架的打包和部署过程中向后工作是有意义的。一些框架包括一个部署系统，该系统包装了本指南其余部分中概述的技术。在这些情况下，为了获得最简单和最可靠的生产体验，您需要遵从框架的打包指南。
如果你想知道这些平台和框架是如何在引擎盖下工作的，你可以一直阅读后面的部分。
取决于预装的python¶
选择一台任意的计算机，根据上下文，很有可能已经安装了python。默认情况下，在大多数Linux和Mac操作系统中包括许多年了，您可以合理地依赖先前存在于数据中心或开发人员和数据科学家的个人机器上的python。
支持此模型的技术：
注解
在这里的所有方法中，依赖于预安装的python对目标环境的依赖性最大。当然，这也使得最小的包，小到一个数字兆字节，甚至千字节。
一般来说，减少对目标系统的依赖会增加包的大小，因此这里的解决方案大致是通过增加输出大小来安排的。
取决于单独的软件分发生态系统¶
长期以来，许多操作系统，包括Mac和Windows，都缺乏内置的包管理。直到最近，这些操作系统才获得了所谓的“应用商店”，但即使是那些专注于消费者应用程序的应用商店，也很少为开发人员提供服务。
开发人员长期寻求补救措施，在这场斗争中，出现了他们自己的包管理解决方案，如 Homebrew . 对于Python开发人员来说，最相关的替代方案是一个称为 Anaconda . Python 是围绕着python构建的，在学术、分析和其他面向数据的环境中越来越常见，甚至正在形成自己的方式。 into server-oriented environments .
关于建立和出版水蟒生态系统的说明：
类似的模型包括安装可选的python发行版，但不支持任意操作系统级别的包：
带来自己的python可执行文件¶
我们所知道的计算是由执行程序的能力来定义的。每个操作系统本机支持一种或多种本机可以执行的程序格式。
有许多技术和技术可以将您的python程序转换成这些格式之一，其中大部分涉及将python解释器和任何其他依赖项嵌入到单个可执行文件中。
这种方法叫做 冰冻的 提供了广泛的兼容性和无缝的用户体验，尽管通常需要多种技术和大量的工作。
一系列python冰柜：
pyInstaller -跨平台
cx_Freeze -跨平台
constructor -对于命令行安装程序
py2exe -仅限Windows
py2app -仅限Mac
bbFreeze -仅限Windows、Linux、python 2
osnap -Windows和Mac
pynsist -仅限Windows
以上大多数都意味着单用户部署。有关多组件服务器应用程序，请参阅 Chef Omnibus .
带来你自己的用户空间¶
越来越多的操作系统（包括Linux、Mac OS和Windows）可以设置为运行打包为轻量级映像的应用程序，使用相对现代的排列方式，通常被称为 operating-system-level virtualization 或 集装箱化 .
这些技术大多不支持Python，因为它们打包了整个OS文件系统，而不仅仅是Python或Python包。
在Linux服务器中采用最广泛，在这些服务器中，技术的起源和下面的技术最有效：
带着你自己的内核¶
大多数操作系统支持某种形式的经典虚拟化，运行打包为映像的应用程序，其中包含自己的完整操作系统。运行这些虚拟机（vms）是一种成熟的方法，广泛应用于数据中心环境中。
这些技术主要是为数据中心中的大规模部署保留的，尽管某些复杂的应用程序可以从这种打包中受益。技术与python无关，包括：
VHD, AMI, and other formats
OpenStack -python中的云管理系统，具有广泛的虚拟机支持
带上你自己的硬件¶
最全面的方式来运送你的软件将是运送它已经安装在一些硬件上。这样，您的软件用户只需要电力。
虽然上面描述的虚拟机主要是为精通技术的人保留的，但是您可以发现从最先进的数据中心到最年轻的孩子，每个人都在使用硬件设备。
将代码嵌入到 Adafruit ， MicroPython 或者运行python的更强大的硬件，然后将其发送到数据中心或用户的家中。他们即插即用，你可以称之为一天。
用于打包python应用程序的简化技术。¶
那……¶
上面的部分只能总结这么多，您可能会想知道一些更明显的差距。
操作系统包¶
如上所述 取决于单独的软件分发生态系统 上面，一些操作系统有自己的包管理器。如果您非常确定要瞄准的操作系统，则可以直接依赖以下格式 deb （对于Debian、Ubuntu等）或 RPM （对于RedHat、Fedora等），并使用内置的包管理器来处理安装，甚至部署。你甚至可以用 FPM 从同一个源生成DEB和RPM。
在大多数部署管道中，OS包管理器只是难题的一部分。
虚拟现实¶
Virtualenvs 对于多代的Python开发人员来说，这是一个不可或缺的工具，但是随着它们被更高级别的工具所包围，它们正在慢慢地从视图中消失。尤其是在打包过程中，virtualenv被用作 the dh-virtualenv tool 和 osnap 两者都以独立的方式包装虚拟环境。
对于生产部署，不要依赖于运行 pip install 从互联网到虚拟环境，就像在开发环境中一样。上面的概述充满了更好的解决方案。
安全性¶
随着坡度的降低，更新包的组件就越困难。一切都更加紧密地结合在一起。
例如，如果出现内核安全问题，并且您正在部署容器，则可以更新主机系统的内核，而不需要代表应用程序进行新的构建。如果部署VM映像，则需要新的构建。这一动态是否会使一个选项更加安全，仍然是一个古老的争论，回到仍然悬而未决的问题 static versus dynamic linking .