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 文件位置（如下图）。

2、开启 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