大多数编程语言包的生态系统都有两个层级(level)：每个包都有一个或多个发布(release)，每一次发布都可以用版本号(version)进行区分。Python 有第三个层级：每个发布都有一个或多个发行版(distribution)，下载安装包时下载的实际文件就是这些发行版。在大多数语言中，这些文件都是发布的同义词，但是在Python 中「一个发布有多个发行版」是很重要的，因为使用最广泛的那些包，大多数发布实际上都有多个发行版。
为什么会这样呢？因为 Python 的特殊之处在于，它将 C 扩展(extension)视为该语言的一流特性，并试图隔离包的使用与编译 C 扩展。这意味着发行版需要包含编译 C 扩展后的得到的二进制代码，这种发行版(在其现代迭代中)被称为 binary wheels。
但是 C 扩展通常需要针对特定的 Python 版本和操作系统进行编译，因此需要使用多个 wheels 来实现普适性。此外，由于包的作者不能预测出所有的 Python 版本和操作系统，所以包含一个由包用户负责编译的源发行版也很重要。
尽管如此，用户们和大多数工具考虑的仍然是发布版本(release)，而不是特定的发行版(distribution)。这可能会引起极大的不协调。例如，在一台机器上安装一个包可能需要几秒钟(因为存在匹配的二进制发行版)，在另一台机器上可能需要几分钟甚至几个小时。
即使两台机器都能找到合适的二进制发行版来安装，它们的哈希值也不匹配，检测 MitM 攻击也会因此变得更加困难。因为 pip 这样的工具会自动找到在发布下「最合适」的发行版，当一个发行版与给定的系统兼容时会偏向于选择 binary wheel，如果有多个发行版与此系统兼容，则选择最合适的 binary wheel，如果不兼容，则返回到源发行版。
如果你已经安装了发布下的一个发行版之后，该发布又有一个新的发行版，这时就会出现很大的问题。而且这个问题几乎是不可避免的——因为 PyPI 一次只允许上传一个发行版，并会创建一包含这个发行版的新发布，所以在你上传最后一个发行版之前，一定会有人已经下载了第一个发行版。
在使用自动编译程序(buildbot)并行构建不同的发行版之后，这个问题变得更加常见，二进制发行版一般要比源发行版花费更长的时间。当一个包的作者在发布后的几个月或几年里，再去添加对新平台(或 python 的新版本)的支持时，这种情况就变得更糟糕了。当这种情况发生时，会有以下一些问题:构建一个系统，期待在给定包中断时产生一个特定的哈希值。
像 PyDist 这样的 PyPI 镜像不知道要查找新的发行版，并且无法同步。
你的系统(如开发机器)如果先前安装了某发布的一个发行版，这个系统就不会获得。
新的发行版，并且可能与安装它的系统(如生产服务器)的行为不同。
尽管 PyPI 维护者已经意识到了这些问题并讨论了工具改进，但是在不显著破坏生态系统的情况下解决这些问题的方法还是很难找到的。与此同时，Python 重度用户和系统管理员也有责任了解 Python 包的分布方式以及 pip 如何选择发行版。
