Composer 终于走到了 v1.0 版本

Composer 项目刚刚宣布在其第五个生日的同一天发布了 V1.0 正式版

以下翻译自 Composer 创始人 Jordi Boggiano 的原文:

五年前的今天,Composer 诞生了。在某些方面,这感觉就像昨天发生的事,至少它不像过去了五年。但在其他方面,好像是上辈子的事了,没有一个完整的 PHP 生态系统,我的手指几乎都不记得如何编写 PHP 代码了。

在这个版本中,Composer 安装工具以及执行 composer self-update 指令都会默认安装最新的 Composer 稳定版本。要知道,以前可都是 alpha 版本啊,五年了!整整五年 alpha 了!Jordi 这样解释道:“如果执行 composer self-update 是你部署流程中的一部分时,这能避免带来破坏,但它也意味着,当我们做任何修改时,反馈会比较曲折“。

如果你想体验 Composer 的最新开发进展,可以将进入 Composer 的 preview 或 snapshot 通道升级。方法为:composer self-update --previewcomposer self-update --snapshot

为了给这次正式版本的发布带来更多惊喜,Composer 团队制作了一个特别的黄金版,并把它放在一张金色的软盘中(如顶图所示)。如果你想收藏的话,可以到 Ebay 网购买。

Packagist/Composer 中国全量镜像重装上阵

其实,Packagist/Composer 中国全量镜像一个月前就已经脱胎换骨、重装上阵了,经过这一个月来的洗礼(内测 + 开放测试),目前每日数据流量接近 10G,日均 IP 2500+。截至目前,各服务器运行平稳,感谢 又拍云 提供的 CDN 支持,和 UCloud 提供的云服务器。

下面说一说这个镜像的细节吧。

composer install 背后到底是怎么运作的?

我们用一张图来说明一下

Composer 就是我们安装在自己系统上的 composer 工具。所有 package 元数据和 zip 文件的下载、安装工作都是它帮我们完成的。

从图上我们可以看到,不管是 Packagist.org 还是 Github.com 出现故障或者被墙,我们都无法正常安装 package,即便能安装的时候,也是龟速。

说到这里,我们看到如果要做镜像的话,单是为 Packagist.org 做镜像显然是不够的,因为它存放的是所有 package 的元数据,真正安装包还在 Github.com 上面呢。所以“全量镜像”就必须将 Packagist.org 和 Github.com 全部镜像才可以。具体到我们的实现来说,就是将 Packagist.org 上的元数据和 Github.com 上面的 zip 包镜像到国内。

Toran Proxy 时代

去年底我们的中国全量镜像上线时用的是 Toran Proxy 搭建的。这个是一个很不错的搭建镜像的工具,而且也是能够同时镜像 Packagist.com 和 Github.com ,并且还是 Composer 作者亲自开发的,兼容、稳定都不会有问题,所以我们就在第一时间用 Toran Proxy 在国内搭建了一个镜像。但是问题很快就显露了出来,下面挨个说一说:

1、“墙”

国内的开发者之所以抱怨 composer install 慢,就是因为国内到国外(Packagist 主站和 Github 的服务器都在国外)的带宽低,不稳定,而且时不时还被“墙”。由于我们意在帮助国内开发者解决痛点,因此必然要将 Toran Proxy 搭建在国内才能起到加速作用,当然,低带宽和墙都是绕不过去的坑。接下来我们就找解决方案吧,只有两种方案:一是将 Toran Proxy 搭建在国外,比如可以放在香港(香港是中国不可分割的一部分!);二是在国外搭建一个 VPN ,让 Toran Proxy 走 VPN 通道。

对于第一种方案,虽然能够顺畅访问 Packagist 和 Github 了,但是大陆到国外访问速度仍然受限,镜像的意义是为了加速 package 的安装的,速度慢也就失去了这个存在的意义。况且,一但流量大了,单机无法承受负载、带宽也非常昂贵(在香港购买百兆带宽不是好办法!)。

第二种方案倒是可行,但是,Toran Proxy 不支持 CDN 分流的,势必存在单机负载重,吃带宽的问题。

2、版权问题

上面两种方案貌似第二种还能凑合,但是有一个最大的问题 -- “版权”,Toran Proxy 是 Composer 作者开发出来希望企业能够付费购买,然后将收到的钱用于 Composer 和 Packagist 的继续维护上,我们继续使用 Toran Proxy 搭建镜像的话其实是违反了版权协议,再用下去显然不合适。另外,如果想要 Toran Proxy 支持 CDN 加速的话,势必要对其进行改造,这个更不道义了,Toran Proxy 并非真正的开源产品,对其改造更不合适。

那就只能自己开发一个了!!!

从零开始,自己造一个 Proxy

这就是我们的重点了!我们从零开始重写了一个镜像程序,将 Packagist.org 和 Github.com 完美的镜像到国内,并且通过 又拍云 的 CDN 加速,composer install 的速度提升了至少十几倍。

下面咱就用数据说话,有图有真相!

实验:以 4M 宽带(没办法,家里装不了百兆宽带,10M 也不行,哎!)、普通家用电脑、Laravel 5.1.4 来测试 composer install

  1. 解压 laravel 5.1.4 安装包任意目录
  2. 打开 win7 自带的 powershell 并 cd 进入 laravel 目录
  3. 执行如下命令(确保已经安装了 composer !):
C:\laravel> composer clearcache  
C:\laravel> Measure-Command {composer install -vvv}  

在无缓存的状态下全新安装依赖包总共用时: 52秒;多次统计情况下,平均不超过 60秒。

还有一个哥们给出了更快的速度 -- 10秒(估计是应该是10M或百兆宽带吧,好羡慕):

镜像的实现原理

用图说话:

全量镜像和你同在“中国局域网”内,而且配合 CDN 加速,速度当然杠杠滴!

最后,致谢!

感谢 又拍云 提供的 CDN 支持,和 UCloud 提供的云服务器。

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引用的压缩包。为了强制使用压缩包,而不是克隆源代码,你可以使用installupdate--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 小技巧

Composer -- PHP依赖管理的新时代

对于现代语言而言,包管理器基本上是标配。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 环境变量就可以,不一定要全局安装。

声明依赖

在项目目录下创建一个 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 的官方主页或者中文站点


原文地址:Composer PHP依赖管理的新时代

Composer 是什么

简单来说,Composer 是一个新的安装包管理工具,服务于 PHP 生态系统。它实际上包含了两个部分:ComposerPackagist。下面我们就简单说一下他们各自的用途。

Composer

Composer 是由 Jordi Boggiano 和 Nils Aderman 创造的一个命令行工具,它的使命就是帮你为项目自动安装所依赖的开发包。Composer 中的很多理念都借鉴自 npmBundler,如果你对这两个工具有所了解的话,就会在 composer 中发现他们的身影。Composer 包含了一个依赖解析器,用来处理开发包之间复杂的依赖关系;另外,它还包含了下载器、安装器等有趣的东西。

作为一个用户,你所要做的就是在 composer.json 文件中声明当前项目所依赖的开发包,然后运行 composer.phar install 就行了。composer.json 文件定义了当前项目所依赖的开发包和 composer 的配置信息。下面是一个小型实例:

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

Packagist

Packagist 是 Composer 的默认的开发包仓库。你可以将自己的安装包提交到 packagist,将来你在自己的 VCS (源码管理软件,比如 Github)仓库中新建了 tag 或更新了代码,packagist 都会自动构建一个新的开发包。这就是 packagist 目前的运作方式,将来 packagist 将允许直接上传开发包。