用于 PHP 依赖关系处理的 Composer（2）

look_w

Composer 如何查找库 要下载库包，Composer 首先需要知道在哪里可以找到这些软件包。信息由 Composer 存储库 提供：在线来源列出了                Internet 上提供的软件包、如何检索它们，以及它们自己的依赖关系。虽然任何人都可以维护自己的存储库，以提供对内部库的访问权限（Composer                网站为此提供了  ），但您会使用的主要存储库是  。Packagist 提供为 PHP 中的大部分开源项目提供软件包。您可以去那里找到自己需要的库。
软件库往往不是良好的合作对象。将所有 Packagist 库结合在一起的粘合剂是由   （原名 PHP                Standards Group）提供的，该组织是在   上成立的。成立 PHP-FIG（代表着众多流行的 PHP                应用程序和框架的一组人）就是为了看看人们的项目如何能够更好地协同工作。该合作的高潮是 PHP Standards Recommendations                (PSR) 的创建，它描述库的可选标准。实现这些共同标准的库能够在一组共同的期望下互操作。
最重要的 PSR 是   和  ，它们促进了 Composer                的创建。这些 PSR                为类和命名空间声明一个共同的命名方法，以及它们应该如何将文件映射到文件系统上。然后，一个共同的自动加载程序接口可以从它需要的任何库加载类。创建一个通用的标准方式，让库不需要覆盖彼此就可以共享它们的类，这使得                Composer 变得非常有效。
为自己的项目配置 Composer 现在，您已经知道了如何安装 Composer，了解了自动装载的工作原理，并且能够找到自己想要使用的软件包，我将介绍一个为自己的项目设置                Composer 的示例。
我将会开始编写一个新的 PHP 项目，这是一个小程序，能够将 Markdown 文件转换为 HTML 输出。在 Packagist 搜索                    markdown，显示   库作为一个不错的选择，并显示项目的   的URL，如图 1 所示：
图 1. 在 Packagist 上的库条目
为了告诉 Composer 在您的项目中要包括哪些文件，创建一个名为 composer.json 的配置文件。这个 JSON                格式的文件可以包含各种命令，但您需要的最常用的（而且往往是惟一的）命令是 require                键。我将自己想要的软件包名称以及将要支持的版本传递给这个键：

1 2 3 4 5

{    "require":{       "michelf/php-markdown":"1.4.*"    } }

现在，我可以在我的应用程序目录中运行 composer install。 Composer                需要几分钟来下载我所指定的库要求到一个 vendor 目录中，并为我创建一个包括此目录的自动加载程序。Composer 也创建了另一个文件，即                composer.lock，我会立刻更详细地介绍它。命令和输出看起来如下所示：

1 2 3 4 5 6 7 8 9 10 11 12

> ls composer.json > composer install Loading composer repositories with package information Installing dependencies (including require-dev)   - Installing michelf/php-markdown (1.4.1)     Downloading:100%          Writing lock file Generating autoload files > ls -F composer.json composer.lock vendor/

现在我可以编写依赖于 michelf/php-markdown 软件包的代码。下面简短的 PHP 脚本将完成我想做的工作：

1 2 3 4 5

<?php require 'vendor/autoload.php'; use \Michelf\Markdown; echo Markdown::defaultTransform(file_get_contents("php://stdin"));

多亏了 Composer，我获得了一个简单明了的解决方案。我选择的 Markdown                包碰巧没有额外的依赖关系。但是，如果我选择了一个有依赖关系的软件包，Composer 将在同一时间自动下载所有这些依赖关系并配置它们。
指定版本 您可以根据自己的软件需求，将任意数量的库添加到 composer.json                文件，此外，对于每一个库，您都可以指定想接受的版本。指定版本是一个很重要的部分，可以确保您的软件始终可用。通过在版本号中使用通配符，甚至可以允许                Composer 以您的名义升级库。在前面的示例中，我指定的版本为 "1.4.*"。现在，每当运行                composer install 时，Composer 将查找 1.4 版库的最新版本，但不会接受 1.5、2.0                或其他任何更高版本。如果我希望总是获得库的最新版本，那么我可以指定 "*"（但如果底层 API                被更改，这可能会引起问题）。
表 1 显示，在指定版本限制时可以使用的选项的完整列表。
表 1. 软件包的版本限制规范示例描述确切版本1.0.2软件包的确切版本。范围>=1.0>=1.0 <2.0>=1.0 <1.1 || >=1.2比较运算符可以指定有效版本的范围。有效的运算符是                            >、>=、<、<=                            和 !=。可以定义多个范围，而且默认情况下按照 AND 处理，或者用双竖线                            (||) 分开它们，则作为一个 OR 运算符。连字符范围1.0 - 2.0创建一个包容性的版本集。通配符1.0.*带有 *                            通配符的模式。1.0.* 相当于                            >=1.0 <1.1。波浪运算符~1.2.3“下一个重要版本”：允许最后一位数字增加，因此变得和                            >=1.2.3 <1.3.0 一样。允许最后一位数字增加。^运算符^1.2.3“下一个重要版本”：类似于波浪线运算符，但假设语义版本和直到下一个主要版本的所有变更都应该被允许，因此变得和                            >=1.2.3 <2.0 一样。
软件包稳定性 在配置 Composer                获取项目所需要的准确的库时，另一个要考虑的因素是想要的库版本有多稳定。如果需要最新的版本或正在帮助测试软件，那么可以请求软件包的测试版或开发分支。您可以指定稳定性标志，将它添加到                require 字符串的末尾，并使用 @。例如，为了请求 PHPUnit                的最新开发版本，您可以指定：

1 2 3 4 5

{    "require":{       "phpunit/phpunit":"4.8.*@dev"    } }

对于引用，Packagist 显示存在哪些分支，以及引用它们需要使用的字符串，如                  所示。
版本锁定 使用 Composer 的巨大好处是，版本控制中不需要包括第三方库。在发布软件的新安装时，可以允许 Composer                为您下载并配置所有库，从而保持版本控制清洁。但是，您可能会遇到问题。想象一下，您的网站运行 20                个并发服务器，全部使用不同版本的库，因为代码的部署和 composer install                的运行分别在不同的时间发生。或者更简单地说，多个开发人员可能有不同的库，并且无法复制彼此的错误。其结果可能是灾难性的。
Composer 为这个问题提供了一个解决办法。回想 " " 一节，初次运行 composer install 时创建了一个                composer.lock 文件。该文件指定到底要安装哪些库，以及过程中下载哪些特定的版本。当您将项目提交到版本控制软件中的时候，请提交                composer.lock 文件，而不是 vendor 目录。当准备好一个代码的新部署，并且运行了                composer install 的时候，Composer                会首先查找一个锁定文件。如果找到该文件，则会安装一个与原始安装完全相同的副本，以确保所有安装的一致性。
当然，还需要了解迁移动到新代码版本的方式，最好是采用比删除锁定文件和整个 vendor 目录更好的方式。Composer 以                update 命令的形式提供该工具。当运行 composer update 时，Composer                会参照 JSON                文件的最新配置，比较已安装的软件版本与锁定文件。如果配置允许的较新版本的软件是可用的（或者，如果自上次安装后，新库已被添加到配置），Composer                会下载新的库，并对它们进行相应的配置。
为自己的类创建一个自动加载程序 Composer 还有许多内置的功能，可以在                  中阅读了解这些功能。其中一个最好的功能是，您可以在配置中指定自己的类，这使得 Composer                可以自动在自动加载程序中生成项目的代码。此功能让您免于自己创建独立于 Composer 的自动加载程序。
在这里，我可以更新以前的 composer.json 文件来创建自己的自动加载程序：

1 2 3 4 5 6 7 8

{   "require":{     "michelf/php-markdown":"1.4.*"   },   "autoload":{     "psr-4":{"Converter\\":"src/"}   } }

在本例中，我指定了一个名为 Converter 的命名空间，并说明该命名空间的所有类文件均存在于名为 src                的相对目录中。所以，如果我有一个名为 Converter\CommandLine                的类，自动加载程序将会查找这个类，它在文件系统中被保存为 src / CommandLine.php。这个文件现在是为我生成的一个 PSR-4                兼容的自动加载程序。
提供自己的软件包 此时，我可以将 Markdown 到 HTML 的转换器应用程序提供为一个 Packagist                上的软件包。（由于转换器是一个应用程序，而不是一个可重用的库，将它作为一个软件包提供并没有实际意义，但是，为了本练习的需要，我们假装它是一个库）。从本质上讲，通过创建我的                composer.json 文件，该应用程序本身是一个软件包，可以安装它。包名称的格式必须是                vendor/package。所以，在我的例子中，我将下面的代码添加到配置文件：

1	"name":"EliW/Converter",

其他一些配置也值得补充。您可以将所需的 PHP 版本指定为 Composer 将执行的虚拟软件包名称。（您有许多选项，可以强制版本号，而不是让                Composer 假定标准的版本控制系统模式。您可以提供元数据，让软件包列表看起来像是完整的。）为了指定 PHP                版本号，并将我自己的转换器打包为完整的软件包，我会这样做：

1 2 3 4 5 6 7

{   "name":"EliW/Converter",   "require":{     "michelf/php-markdown":"1.4.*",     "php":">=5.3.0"   }, }

配置现在是完整的。当我将自己的应用程序提交给一个在线版本控制系统（如 GitHub），我可以登录到我的 Packagist                帐户，并提交我的软件包信息，让其他人可以将我的应用程序包含在他们的项目中。
结束语 在本期   文章中，我介绍了如何使用 Composer 从第三方库组装项目的基本知识。查看  ，找到有关 Composer                的不常用功能的更深入讨论，并了解如何托管自己的内部库，而无需通过 Packagist 帮助组织复杂的代码库。
按照本文章系列的进展，我已经介绍了 PHP                本身的演变过程，它如何满足现代安全要求，以及它如何采用现代的依赖关系管理和软件包管理系统来处理日益复杂的现代代码库。在下期文章中，我将讨论 PHP                生态系统的发展情况，让开发人员可以通过使用 PuPHPet 来管理其部署和开发环境。