Question

许多软件都会使用一些库和独立维护的软件包。对于开发者而言，这是一件好事，因为这种做法有利于代码复用，而且他们可专注于创建新的功能，而无需重复造轮。然而，这种做法也会付出一定的代价。如果某个程序的正常运行必须依赖于另一个库，则用户或这款软件必须确保任何运行该程序代码的机器都已安装了依赖库。乍看上去，这几乎不算一个问题——只需随这款软件一起安装所需的依赖库不就行了？不幸的是，这种方法会带来一些意想不到的后果，而且常常如此。

设想如下场景：你找到一款出色的软件——软件A，下载后开始安装。在执行其安装脚本时，软件A需要另外一款依赖软件。如果你的计算机中缺少这个依赖软件，则需进行安装。我们称之为软件依赖项（software dependency）。假设该依赖项的当前版本号为1.0。软件A先安装1.0版的依赖项，然后再对自身进行安装，一切都进行得很顺利。再假设将来的某个时候，你偶然发现了另一款希望安装的软件——软件B。软件B需要使用2.0版的依赖项，相对于1.0版，这个版本做出了重大改进，且不具备向下兼容性。鉴于这个依赖项的发行方式，无法做到1.0和2.0两个版本同时运行，因为这将导致使用它时产生二义性（这两个版本的都会作为依赖项被导入，应使用哪个版本？）。最终，软件B将用2.0版的依赖项覆盖1.0版，并完成自身的安装。经历一番艰辛后，你才发现软件A与2.0版依赖项不兼容，因此完全被破坏，情况顿时变得很糟。如何才能在同一台机器上既可运行软件A，也可运行软件B？这个问题非常重要，因为TensorFlow也依赖于若干开源软件。利用Python（用于将TensorFlow打包的编程语言），可采取多种方式避免上述依赖冲突问题。

代码库内部的软件包依赖。无需依赖于系统级的软件包或库，开发者可将所需版本的依赖库放在自己的代码中，并在局部引用。按照这种方式，软件所需的所有代码都是可直接操控的，不会受到外部变动的影响。然而，这种方式并非无懈可击。首先，它增加了安装该软件所需的磁盘空间，这意味着安装时间更长、使用成本更高。其次，用户可能已经以全局方式安装了依赖库，这意味着局部版本完全是多余的，会占用不必要的空间。最后，依赖库在将来可能会推出修复若干严重安全漏洞的关键的、保持向下兼容性的更新。这时，对代码库中依赖库的更新将无法借助软件包管理器，而只能由软件开发者手工完成。不幸的是，最终用户对此无从插手，因为何时直接包含依赖库完全是由开发者决定的。有一些依赖库由于没有被包含进TensorFlow，因此必须单独安装。

使用依赖环境。一些软件包管理器中包含可创建虚拟环境的相关软件。在一个环境中可完全独立地维护特定版本的软件而不受其他环境的影响。借助Python，有多种选择。对于Python的标准发行版，Virtualenv是直接可用的。如果使用的是Anaconda，它会包含一个内置的虚拟环境系统及其软件包管理器——Conda。稍后，笔者将会介绍如何使用这两种工具安装TensorFlow。

使用容器。容器（如Docker）是将软件与完整的文件系统，包括其运行时和依赖库打包的轻量级方案。因此，任何可运行一个容器的机器（包括虚拟机在内）都能够与任何运行该容器的其他机器对其中所包含的软件获得完全相同的运行效果。与简单地激活Virtualenv环境或Conda环境相比，虽然从Docker中启动TensorFlow需要略多一点的步骤，但当需要将代码在不同实例（无论是虚拟机还是物理的服务器）上进行部署时，它在不同运行时环境中的一致性使其成为无价之宝。下文将介绍如何安装Docker，并创建你自己的TensorFlow容器（以及如何使用官方的TensorFlow镜像）。

一般而言，如果准备在单机上安装和使用TensorFlow，笔者建议采用Virtualenv或Conda的虚拟环境。它们能够以较小的代价解决依赖冲突问题，且易于设置。一旦创建完毕，便几乎一劳永逸。如果准备将TensorFlow代码部署到一台或多台服务器中，则值得创建一个Docker容器镜像。虽然所需的步骤略多，但却会大大降低在多服务器上部署的成本。笔者不推荐既不使用虚拟环境，也不使用容器的TensorFlow安装方法。