php composer 相关及版本约束等小技巧

对于现代语言而言，包管理器基本上是标配。Java有Maven，Python有pip，Ruby有gem，Nodejs有npm。PHP的则是PEAR，不过PEAR坑很多：

• 依赖处理容易出问题
• 配置很是复杂
• 难用的命令行接口

好在咱们有Composer，PHP依赖管理的利器。它是开源的，使用起来也很简单，提交本身的包也很容易。

安装Composer

Composer须要PHP 5.3.2+才能运行。

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

这个命令会将composer.phar下载到当前目录。PHAR（PHP 压缩包）是一个压缩格式，能够在命令行下直接运行。

你可使用--install-dir选项将Composer安装到指定的目录，例如：

$ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin 

固然也能够进行全局安装：

$ curl -sS https://getcomposer.org/installer | php $ mv composer.phar /usr/local/bin/composer 

在Mac OS X下也可使用homebrew安装：

brew tap josegonzalez/homebrew-php
brew install josegonzalez/php/composer 

不过一般状况下只需将composer.phar的位置加入到PATH就能够，不必定要全局安装。

或者咱们之间下载windows 安装程序：http://getcomposer.org/Composer-Setup.exe

基本是脑下一步便可，期间注意指定正确的 php.exe 文件位置（以下图）。

二、开启 php_openssl 拓展

此步骤须要注意的是，使用集成环境的同窗有可能在开启集成环境中 php_openssl 拓展后仍然法正常进行下一步，若在下一步中出现下图提示，那么请手动打开 php 目录下的 php.ini 文件，亲自确认 extension=php_openssl.dll 是否已经开启。

 

 

两年前，我想摆脱丑陋的PEAR，我在symfony1中用它来支持插件。我想找一个项目依赖管理软件来替代它，不像PEAR须要安装。管理依赖并不容易，因此我试图寻找最好的算法来管理软件依赖，我找遍了一切技术，从Perl到Ruby，从Debian到Redhat。但都不能让人满意。根据经验，原生的解决方案可能会有用。而后，我偶然发现了ZYpp，就是它了。ZYpp使用SAT来管理软件依赖。如今，多亏Nils Adermann 和 Jordi Boggiano的辛勤工做，PHP拥有了最好的依赖管理软件之一：Composer。

是的，PHP的依赖管理软件比其余语言都要好。

并且因为有Git、Composer和PHP内嵌的web服务器，下载、安装测试PHP工程要容易得多。

想测试Symfony(用PHP5.4)？只要执行：

 

$ composer.phar create-project symfony/framework-standard-edition
$ cd framework-standard-edition
$ ./app/console server:run

想测试Silex？执行：

 

$ composer.phar create-project fabpot/silex-skeleton
$ cd silex-skeleton
$ php -S localhost:8888 -t web/

还不知道Composer？你应该了解它。访问Packagist(Composer的主仓库)：那里已有超过1900个包，并且在三个月中已经被安装了上百万次。

下一个挑战：在PHP的下个版本中加入Composer安装程序？

Your project, with its
dependencies, is defined with a JSON file, called composer.json. Composer reads the
contents of this file and connects to Packagist, (https://packagist.org/) an online
repository, to resolve the different dependencies, recursively.

Finding and installing new packages

Using the search on http://packagist.org, you can find packages to add common
features, such as image manipulation or PDF generation to your application.
Indicators of good packages beyond the number of downloads and the number of
stars on GitHub are the quality of documentation, the test coverage, and the overall
project activity. Before adding a new package, you can also browse the different
versions of a package and its dependencies on Packagist:

声明依赖

在项目目录下建立一个composer.json文件，指明依赖，好比，你的项目依赖 monolog：

{
    "require": { "monolog/monolog": "1.2.*" } } 

安装依赖

安装依赖很是简单，只需在项目目录下运行：

composer install

若是没有全局安装的话，则运行：

php composer.phar install

自动加载

Composer提供了自动加载的特性，只需在你的代码的初始化部分中加入下面一行：

require 'vendor/autoload.php';

模块仓库

packagist.org是Composer的仓库，不少著名的PHP库都能在其中找到。你也能够提交你本身的做品。

高级特性

以上介绍了Composer 的基本用法。Composer还有一些高级特性，虽然不是必需的，可是每每能给PHP开发带来方便。

项目主页

更多信息请访问 Composer 的主页。

参考：http://article.yeeyan.org/view/101013/320904

更多：http://segmentfault.com/a/1190000000353129

 

PHP 开发者该知道的 5 个 Composer 小技巧

Composer 是新一代的PHP依赖管理工具。其介绍和基本用法能够看这篇《Composer PHP依赖管理的新时代》。本文介绍使用Composer的五个小技巧，但愿能给你的PHP开发带来方便。

1. 仅更新单个库

只想更新某个特定的库，不想更新它的全部依赖，很简单：

composer update foo/bar

此外，这个技巧还能够用来解决“警告信息问题”。你必定见过这样的警告信息：

Warning: The lock file is not up to date with the latest changes in composer.json, you may be getting outdated dependencies, run update to update them. 

擦，哪里出问题了？别惊慌！若是你编辑了composer.json，你应该会看到这样的信息。好比，若是你增长或更新了细节信息，好比库的描述、做者、更多参数，甚至仅仅增长了一个空格，都会改变文件的md5sum。而后Composer就会警告你哈希值和composer.lock中记载的不一样。

那么咱们该怎么办呢？update命令能够更新lock文件，可是若是仅仅增长了一些描述，应该是不打算更新任何库。这种状况下，只需update nothing：

$ composer update nothing
Loading composer repositories with package information  
Updating dependencies  
Nothing to install or update  
Writing lock file  
Generating autoload files

这样一来，Composer不会更新库，可是会更新composer.lock。注意nothing并非update命令的关键字。只是没有nothing 这个包致使的结果。若是你输入foobar，结果也同样。

若是你用的Composer版本足够新，那么你能够直接使用--lock选项：

composer update --lock

2. 不编辑composer.json的状况下安装库

你可能会以为每安装一个库都须要修改composer.json太麻烦，那么你能够直接使用require命令。

composer require "foo/bar:1.0.0" 

这个方法也能够用来快速地新开一个项目。init命令有--require选项，能够自动编写composer.json：（注意咱们使用-n，这样就不用回答问题）

$ composer init --require=foo/bar:1.0.0 -n $ cat composer.json { "require": { "foo/bar": "1.0.0" } } 

3. 派生很容易

初始化的时候，你试过create-project命令么？

composer create-project doctrine/orm path 2.2.0 

这会自动克隆仓库，并检出指定的版本。克隆库的时候用这个命令很方便，不须要搜寻原始的URI了。

4. 考虑缓存，dist包优先

最近一年以来的Composer会自动存档你下载的dist包。默认设置下，dist包用于加了tag的版本，例如"symfony/symfony": "v2.1.4"，或者是通配符或版本区间，"2.1.*"或">=2.2,<2.3-dev"（若是你使用stable做为你的minimum-stability）。

dist包也能够用于诸如dev-master之类的分支，Github容许你下载某个git引用的压缩包。为了强制使用压缩包，而不是克隆源代码，你可使用install和update的--prefer-dist选项。

下面是一个例子（我使用了--profile选项来显示执行时间）：

$ composer init --require="twig/twig:1.*" -n --profile Memory usage: 3.94MB (peak: 4.08MB), time: 0s $ composer install --profile Loading composer repositories with package information Installing dependencies - Installing twig/twig (v1.12.2) Downloading: 100% Writing lock file Generating autoload files Memory usage: 10.13MB (peak: 12.65MB), time: 4.71s $ rm -rf vendor $ composer install --profile Loading composer repositories with package information Installing dependencies from lock file - Installing twig/twig (v1.12.2) Loading from cache Generating autoload files Memory usage: 4.96MB (peak: 5.57MB), time: 0.45s 

这里，twig/twig:1.12.2的压缩包被保存在~/.composer/cache/files/twig/twig/1.12.2.0-v1.12.2.zip。从新安装包时直接使用。

5. 若要修改，源代码优先

当你须要修改库的时候，克隆源代码就比下载包方便了。你可使用--prefer-source来强制选择克隆源代码。

composer update symfony/yaml --prefer-source

接下来你能够修改文件：

composer status -v  
You have changes in the following dependencies: /path/to/app/vendor/symfony/yaml/Symfony/Component/Yaml: M Dumper.php 

当你试图更新一个修改过的库的时候，Composer会提醒你，询问是否放弃修改：

$ composer update
Loading composer repositories with package information  
Updating dependencies  
  - Updating symfony/symfony v2.2.0 (v2.2.0- => v2.2.0) The package has modified files: M Dumper.php Discard changes [y,n,v,s,?]? 

为生产环境做准备

最后提醒一下，在部署代码到生产环境的时候，别忘了优化一下自动加载：

composer dump-autoload --optimize

安装包的时候能够一样使用--optimize-autoloader。不加这一选项，你可能会发现20%到25%的性能损失。

若是你须要帮助，或者想要了解某个命令的细节，你能够阅读官方文档或者中文文档，也能够查看JoliCode作的这个交互式备忘单。

---

原文地址：5 features to know about Composer PHP 
译文地址：PHP 开发者该知道的 5 个 Composer 小技巧

更多：

http://blog.csdn.net/panpan639944806/article/details/16808261

 

版本约束:

须要注意的时，包能升级的版本会受到版本约束的约束，包不会升级到超出约束的版本的范围。例如若是 composer.json 里包的版本约束为 ^1.10 ，而最新版本为2.0。那么 update 命令是不能把包升级到2.0版本的，只能最高升级到1.x版本。关于版本约束请看后面的介绍。

版本约束

前面说到，咱们能够指定要下载的包的版本。例如咱们想要下载版本1.19的monolog。咱们能够经过 composer.json 文件：

{
    "require": { "monolog/monolog": "1.19" } }

而后运行 install 命令，或者经过 require 命令达到目的：

$ composer require monolog/monolog:1.19 # 或者 $ composer require monolog/monolog=1.19 # 或者 $composer require monolog/monolog 1.19

除了像上面那样指定具体的版本，咱们还能够经过不一样的约束方式去指定版本。

基本约束

精确版本

能够指定具体的版本，告诉Composer只能安装这个版本。可是若是其余的依赖须要用到其余的版本，则包的安装或者更新最后会失败并终止。

例子： 1.0.2

范围

使用比较操做符你能够指定包的范围。这些操做符包括： > ， >= ， < ， <= ， != 。

你能够定义多个范围，使用空格 或者逗号 , 表示逻辑上的与，使用双竖线 || 表示逻辑上的或。其中与的优先级会大于或。

须要注意的是，使用没有边界的范围有可能会致使安装不可预知的版本，并破坏向下的兼容性。建议使用折音号操做符。

例子：

• >=1.0

• >=1.0 <2.0

• >=1.0 <1.1 || >=1.2

范围（使用连字符）

带连字符的范围代表了包含的版本范围，意味着确定是有边界的。其中连字符的左边代表了 >=的版本，而连字符的右边状况则稍微有点复杂。若是右边的版本不是完整的版本号，则会被使用通配符进行补全。例如 1.0 - 2.0 等同于 >=1.0.0 <2.1 （ 2.0 至关于 2.0.* ），而 1.0.0 - 2.1.0 则等同于 >=1.0.0 <=2.1.0 。

例子： 1.0 - 2.0

通配符

可使用通配符去定义版本。 1.0.* 至关于 >=1.0 <1.1 。

例子： 1.0.*

下一个重要版本操做符

波浪号 ~

咱们先经过后面这个例子去解释 ~ 操做符的用法： ~1.2 至关于 >=1.2 <2.0.0 ，而 ~1.2.3至关于 >=1.2.3 <1.3.0 。对于使用 Semantic Versioning 做为版本号标准的项目来讲，这种版本约束方式很实用。例如 ~1.2 定义了最小的小版本号，而后你能够升级2.0如下的任何版本而不会出问题，由于按照 Semantic Versioning 的版本定义，小版本的升级不该该有兼容性的问题。简单来讲， ~ 定义了最小的版本，而且容许版本的最后一位版本号进行升级（没懂得话，请再看一边前面的例子）。

例子： ~1.2

须要注意的是，若是 ~ 做用在主版本号上，例如 ~1 ，按照上面的说法，Composer能够安装版本1之后的主版本，可是事实上是 ~1 会被看成 ~1.0 对待，只能增长小版本，不能增长主版本。

折音号 ^

^ 操做符的行为跟 Semantic Versioning 有比较大的关联，它容许升级版本到安全的版本。例如， ^1.2.3 至关于 >=1.2.3 <2.0.0 ，由于在2.0版本前的版本应该都没有兼容性的问题。而对于1.0以前的版本，这种约束方式也考虑到了安全问题，例如 ^0.3 会被看成 >=0.3.0 <0.4.0 对待。

例子： ^1.2.3

版本稳定性

若是你没有显式的指定版本的稳定性，Composer会根据使用的操做符，默认在内部指定为 -dev 或者 -stable 。例如：

约束	内部约束
1.2.3	=1.2.3.0-stable
>1.2	>1.2.0.0-stable
>=1.2	>=1.2.0.0-dev
>=1.2-stable	>=1.2.0.0-stable
<1.3	<1.3.0.0-dev
<=1.3	<=1.3.0.0-stable
1 - 2	>=1.0.0.0-dev <3.0.0.0-dev
~1.3	>=1.3.0.0-dev <2.0.0.0-dev
1.4.*	>=1.4.0.0-dev <1.5.0.0-dev

若是你想指定版本只要稳定版本，你能够在版本后面添加后缀 -stable 。

minimum-stability 配置项定义了包在选择版本时对稳定性的选择的默认行为。默认是 stable。它的值以下（按照稳定性排序）： dev ， alpha ， beta ， RC 和 stable 。除了修改这个配置去修改这个默认行为，咱们还能够经过 稳定性标识 （例如 @stable 和 @dev ）来安装一个相比于默认配置不一样稳定性的版本。例如：

{
    "require": { "monolog/monolog": "1.0.*@beta", "acme/foo": "@dev" } }

参考

• https://getcomposer.org/doc/03-cli.md[2]

• https://getcomposer.org/doc/articles/versions.md[3]

• http://semver.org/[1]

转自:https://segmentfault.com/a/1190000005898222?utm_source=tuicool&utm_medium=referral