php依赖composer_用于PHP依赖项处理的Composer

最新推荐文章于 2023-11-14 08:53:08 发布

cuyi7076

最新推荐文章于 2023-11-14 08:53:08 发布

阅读量438

点赞数

文章标签： python linux java 大数据数据库

原文链接：https://www.ibm.com/developerworks/web/library/wa-php-renewed_3/index.html

版权

php依赖composer

随着PHP的成熟，使用它构建的应用程序的复杂性急剧增加。现代PHP开发人员经常依赖第三方库来帮助他们更快地构建软件项目。例如，如果不使用现在可用于PHP的维护良好的第三方库，就无法构建像Facebook这样大小的应用程序。但是，软件重用的好处是要付出代价的：您不仅必须管理应用程序每次安装所需的库列表，而且还必须管理所创建的依赖关系树，因为所使用的每个库都是在其他库的基础上构建的。您如何管理多个库的复杂，相互依存的安排？

PHP开发人员过去常用的两种依赖项处理解决方案已经失去了效力。一种是将所需的任何库与自己的代码一起检查到版本控制存储库中。这项技术在一定程度上有效，但经常造成比解决的麻烦更多的问题。您需要维护自己的库的本地版本。而且，您必须通过下载新版本并将其检入到存储库中来手动实现该库的所有可用错误修复。您最终将在版本控制中获得大量更改日志，而该更改日志与您的实际代码无关。由于这些原因，库通常徘徊在刚开始就被检入的任何版本上，很少更新。

关于本系列

在一个活跃的开源项目的支持下，PHP不断发展，现在它为许多Web提供支持。自从早期作为模板语言以来，PHP就发生了显着变化。如果您多年没有使用或评估PHP技术，您甚至几乎不会认识到一些当前PHP项目。本系列向您展示最新PHP功能以及如何使用当今PHP构建现代，安全的网站。

设计PHP扩展和应用程序存储库（PEAR）项目的部分目的是为了帮助解决这一问题。 PEAR提供了一组库，程序员可以共同参与其中，所有库可以一起工作。 PEAR还包括用于安装所需库及其依赖项（如果有）的命令行工具。长期以来，PEAR是最好的方法，已被许多人使用，但是该系统也有缺点。

PEAR库安装程序全局存储在操作系统上。尽管这种设计消除了将库检入您自己的版本控制存储库的需要，但它带来的问题多于解决的问题。您永远不会确切知道在可能使用的任何系统上正在运行哪些库版本。这种混乱常常成为虚假错误的根源：您将应用程序安装在新服务器上，然后受阻于为什么它无法正常工作，最终意识到有问题的服务器没有正确的PEAR库。而且您需要访问权限来安装这些全局库（共享主机上的许多人都在困扰这个问题）。

“每个人都知道调试的难度是编写程序的两倍。因此，如果您在编写代码时尽可能聪明，那么如何调试它？ ”

布赖恩·克尼根（Brian Kernighan）

2011年4月，两名PHP开发人员Nils Adermann和Jordi Boggiano决定PHP需要一种新的解决方案来解决依赖项处理问题，并开始着手研究。他们于2012年3月1日发布了Composer 。在Composer中，您将创建一个配置文件，该文件指定应用程序需要的第三方库（无论它们在何处托管）。然后运行作曲家谱写自己的完整的应用程序：作曲家下载您所指定的所有库和所有的依赖。本文介绍了Composer的基础知识，并说明了如何在PHP项目中开始使用该工具。

安装作曲家

Composer是一个多平台工具。在任何基于UNIX®或Linux®的计算机上安装都非常简单。您可以通过curl和PHP直接运行安装程序来创建本地安装：

curl -sS https://getcomposer.org/installer | php

前面的命令将Composer的安装创建到本地composer.phar可执行文件中。要使该安装在系统上的任何地方都可以全局访问，请将composer.phar复制到路径中的目录，如本例所示（您可能需要使用sudo来授予自己写入根目录的权限）：

mv composer.phar /usr/local/bin/composer

现在，您可以从系统上任何地方的命令行运行composer 。

在Windows®上，手动安装比较困难，因此Composer的创建者开发了可以下载并运行的安装程序。安装后，可以从Windows命令行使用Composer。

基本用法

Composer是一个功能强大的工具，具有许多惊人的选项。不过，最常见的是，您将根据第三方提供的配置，使用它为第三方PHP应用程序或框架创建/下载/安装代码库。例如，您可以使用Composer安装 Zend Framework及其所有依赖项。使用install命令运行Composer，其余部分由Composer负责。

如果在全球（或在Windows上）安装了Composer，请运行：

composer install

如果仅对一个应用程序执行本地Composer安装，请运行：

php composer.phar install

对于本文的其余部分，我的示例假定您全局安装了Composer。

除了下载项目/应用程序需要的所有库之外，Composer还为您提供了一种轻松地将所有库都包括在内的方法。它将所有库安装到名为vendor的文件夹中，以将其与您自己项目的代码区分开。在供应商文件夹中，它将创建一个名为autoload.php的文件。在项目中包含此文件可为Composer为您下载的所有库设置一个自动加载器：

require 'vendor/autoload.php';

Composer如何查找库

学到更多。开发更多。连接更多。

新的developerWorks Premium会员计划通过Safari图书在线提供对强大的开发工具和资源的无障碍访问，其中包括500个顶级技术标题（数十个专门用于Web开发人员），主要开发人员活动的超低折扣，最近O'Reilly的视频重播会议等。立即注册。

要为您下载库软件包，Composer需要知道从何处可以找到这些软件包。此信息由Composer 存储库提供：列出Internet上可用软件包的联机源，如何检索它们以及它们自身的依赖性是什么。尽管任何人都可以维护自己的存储库以提供对内部库的访问（并且Composer网站提供了这样做的说明），但是您将使用的主要存储库是Packagist 。 Packagist为PHP中的大多数开源项目提供软件包。您可以去那里找到所需的库。

软件库通常不会以协同工作而闻名。将所有Packagist库绑定在一起的粘合剂由PHP Framework Interop组（最初称为PHP Standards Group）提供，该组是在php [tek] 2009大会上创建的。成立了PHP-FIG（代表许多流行PHP应用程序和框架的一群人），以查看他们的项目如何更好地协同工作。合作的高潮是创建PHP标准建议书（PSR），该建议书描述了库的可选标准。实施这些通用标准的图书馆可以在共同的期望下进行互操作。

促成Composer创建的最重要的PSR是PSR-0和PSR-4 。这些PSR声明了类和名称空间的通用命名方法，以及它们应如何映射到文件系统上的文件。反过来，通用的自动加载程序接口可以从所需的任何库中加载类。创建一种通用的，标准化的方法来使库共享其类而不相互覆盖，这使Composer发挥了尽可能高的效率。

为自己的项目配置Composer

现在您已经知道如何安装Composer，了解自动加载的工作原理并可以找到要使用的软件包，下面将以为您自己的项目设置Composer的示例为例。

我将开始编写一个新PHP项目—一个小程序，它将Markdown文件转换为HTML输出。在Packagist上搜索markdown可以将michaelf / php-markdown库作为一个不错的选择，并向我显示该项目主页的URL，如图1所示：

图1. Packagist上的库条目

Packagist上的michelf / php-markdown列表的屏幕截图

要告诉Composer项目中要包含哪些文件，请创建一个名为composer.json的配置文件。此JSON格式的文件可以包含各种命令，但是您将需要的最常见（且通常是唯一）命令是require键。将此密钥传递给我所需的包名称以及支持的版本：

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

现在，我可以在应用程序目录中运行composer install了。 Composer花费几分钟时间将我指定的库要求下载到供应商目录中，并为我创建一个包含该目录的自动加载器。 Composer还创建了另一个文件composer.lock，稍后我将对其进行详细描述。命令和输出如下所示：

> 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脚本将满足我的要求：

<?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` `>=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`	“下一个重要版本”：与tilde运算符类似，但假定语义版本化，并且应允许对下一个主要版本进行所有更改，因此与`>=1.2.3 <2.0` 。

包装稳定性

配置Composer以准确获取项目所需的库的另一个注意事项是希望库发行版的稳定性。如果您需要最新版本或正在帮助测试软件，则可以请求软件包的Beta或开发分支。您可以通过使用@将它添加到require字符串的末尾来指定稳定性标志。例如，要请求最新PHPUnit开发版本，可以指定：

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

作为参考，Packagist向您显示存在哪些分支以及引用它们需要使用的字符串，如图1所示。

版本锁定

使用Composer的一大好处是您不需要在版本控制中包括第三方库。发布新安装的软件时，可以通过允许Composer为您下载和配置所有库来保持版本控制的整洁。但是，您可能会遇到问题。想象一下，为您的网站运行20个并发服务器，它们全部使用不同版本的库，因为在不同的时间部署了代码，并运行了composer install 。更简单地说，多个开发人员可能都拥有不同的库，并且无法复制彼此的错误。结果可能是灾难性的。

Composer提供了针对此问题的解决方案。回顾“ 为自己的项目配置Composer ”部分，最初运行composer install会创建一个composer.lock文件。该文件准确指定了在安装过程中安装了哪些库以及下载了哪些特定版本。当您将项目提交到版本控制软件中时，请提交composer.lock文件，而不是供应商目录。当准备好新的代码部署并运行composer install ，Composer将首先查找锁定文件。如果找到它，它将安装与原始安装完全相同的副本，从而确保整个安装的一致性。

当然，还需要一种方法以继续使用较新版本的代码-最好是比删除锁定文件和整个供应商目录更好的方法。 Composer以update命令的形式提供此功能。当您运行composer update ，Composer会将通过锁定文件安装的软件版本与JSON文件中的最新配置进行比较。如果配置允许使用较新版本的软件（或者自上次安装以来已将新库添加到配置中），则Composer将下载新库并在适当位置进行配置。

为自己的课程创建自动加载器

Composer内置了许多其他功能，您可以在文档中继续阅读。最好的功能之一是，您可以在配置中指定自己的类，这使Composer可以将项目的代码自动构建到其自动加载器中。此功能使您无需创建独立于Composer的自动加载器。

在这里，我更新了先前的composer.json文件以创建自己的自动加载器：

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

在此示例中，我指定了一个名为Converter的命名空间，并指示该命名空间的所有类文件都存在于名为src的相对目录中。因此，如果我有一个名为Converter\CommandLine的类，则自动加载器将查找该类以src / CommandLine.php的形式保存在文件系统中。该文件现在是为我生成的PSR-4兼容自动加载器。

提供自己的包裹

至此，我可以将Markdown-to-HTML转换器应用程序作为Packagist上的软件包提供。（因为转换器是一个应用程序，而不是可以重用的库，将它作为软件包提供实际上没有任何意义-但出于本练习的目的，假装它是一个库。）本质上，通过创建我的composer.json文件，该应用程序本身是一个包，可以安装。软件包名称必须采用vendor/package的格式。因此，就我而言，我将其添加到配置文件中：

"name": "EliW/Converter",

其他一些配置值得添加。您可以将所需PHP版本指定为Composer将强制执行的虚拟包名称。（在许多其他选项中，您可以强制版本号而不是允许Composer采取标准的版本控制系统模式。并且您可以提供元数据以使软件包清单看起来完整。）要指定PHP版本号并打包我自己的版本转换器作为其自己的完整软件包，我可以这样做：

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

至此配置完成。将我的应用程序提交到诸如GitHub之类的在线版本控制系统后，我可以登录到Packagist帐户并提交我的软件包信息，以使我的应用程序可供其他人包括在他们的项目中。

结论

在这本PHP更新的文章中，我向您提供了如何使用Composer从第三方库组装项目的基础知识。查阅在线文档，以更深入地讨论Composer较少使用的功能，并了解如何可以托管自己的内部库而无需通过Packagist来帮助组织复杂的代码库。

随着本系列的进展，我已经展示了PHP本身是如何发展的，如何满足现代安全性要求的，以及它如何采用现代的依赖项管理和包管理系统来处理现代代码库日益增加的复杂性。在下一部分中，我将讨论PHP生态系统如何演变，以使开发人员能够通过使用PuPHPet来管理其部署和开发环境。

翻译自: https://www.ibm.com/developerworks/web/library/wa-php-renewed_3/index.html