在PHP包管理上面，PHP發展的很緩慢，導致的結果就是很少發現程序員會使用像PEAR這樣的工具。相反，大多數開發人員會選擇他們自己喜歡的框架來處理代碼，比如DB交互、ORIM’S、Oauth、Amazon S3整合等。
缺點就是在轉換框架的時候（或者根本不需要返回使用框架）就感覺像在做噩夢，因為涉及到使用新工具，你必須重新學習里面的一切東西，而這並不簡單。OK，Composer來幫助你解決這些問題。
介紹
Composer通過把自己定位成“所有項目的粘合計”來着手解決問題。這也就意味着包可以被寫，開發和以某種格式進行共享，其他開發人員可以輕松插入到應用程序中。
這篇文章將向大家講解如何安裝和使用Composer包。在文章最后，你就可以把代碼塊插入到任何一個框架中進行體驗，你可以使用CodeIgniter，FuelPHP，Laravel，Symfony2,Lithium，Yii，Zend等。
安裝
Composer包含兩大邏輯部分：一個是用來存儲包，另一個是命令行應用程序，幫助你發現、下載、更新和分享代碼。
- $ cd/path/to/my/project
- $ curl -s http://getcomposer.org/installer| php
在項目列表中，會有一個composer.phar文件，里面包含了所有邏輯代碼行工具。你可以通過運行下面代碼來確定是否安裝成功。
- $ php composer.phar
這個命令執行后會顯示所有可用的命令。
我個人比較建議大家使用這個命令：
- $ sudo mv composer.phar /usr/bin/composer
把這個文件移到bin目錄下，它允許你簡化命令。
- $ composer about
如果你是在Windows上運行，你可以下載這個文件，然后通過PHP解析器安裝，無論在哪里都可以。
解析composer.json文件
如果你是一名Ruby程序員，你會覺得這個文件跟Gemfile文件很相似，或者你是一個Node程序員，那么會覺得和package.json文件很像。同樣，Composer會根據你的應用需求用composer.json文件來指定設置和封裝。
在大多數基本的form里面，composer文件看起來是這樣的：
- {
- "require": {
- "kriswallsmith/assetic": "*"
- }
- }
意思是需要一個“assetic”包，通過“kriswallsmith”創建和指定任意一個版本。你也可以指定一個特殊的版本，你可以使用下面命令代替：
- "kriswallsmith/assetic": "1.0.3"
你甚至還可以使用這種方法：
- "kriswallsmith/assetic": "1.0.*"
這個有一些微小的變化，但是他不會升級到1.1.0，程序員需要注意界面上細微的變化。
安裝要求
現在，在你的composer.json文件下面會有一個或多個包，這個時候可以運行：
- $ php composer.phar install
或者，如果你聽了我的建議，你只需要在Unix機器上面運行：
- $ composer install
你會發現，正在下載文件並且會放在應用程序根目錄下面的vendors文件夾里面。這個邏輯也可以使用下面的配置：
- {
- "require": {
- "kriswallsmith/assetic": "1.0.*"
- },
- "config" : {
- "vendor-dir" : "packages"
- }
- }
自動加載
自動加載在PHP里面有一點亂糟糟的，作為開發人員，他們有屬於自己操作方式。比如Smarty包，使用自己的自動載入。有一些開發人員會把多個類放到一個文件里面，或者文件名小寫，這些做法都太隨意啦！
PHP官方社區創建了PSR-0標准，從而來規范這些隨意的做法。Composer默認支持這個標准。Composer里面自帶PSR-0自動加載機制，在項目里面加入下面一行代碼：
- include_once './vendor/autoload.php';
顯然，如果autoload.php文件目錄有變化，你也需要在代碼里面做出相應改動。
下面，你可以在應用程序中使用如下代碼：
- <?php
- use Assetic\Asset\AssetCollection;
- use Assetic\Asset\FileAsset;
- use Assetic\Asset\GlobAsset;
- $js = new AssetCollection(array(
- new GlobAsset('/path/to/js/*'),
- new FileAsset('/path/to/another.js'),
- ));
- // the code is merged when the asset is dumped
- echo $js->dump();
這是一個使用Assetic的例子，當然，這里也有許多命名空間代碼，但是這樣做是為了避免包之間互相沖突。
PSR-0的命名慣例本質是：
- \<Vendor Name>\(<Namespace>\)*<Class Name>
下面這個例子是Buzz HTTP包：
- $browser = new Buzz\Browser;
- $response = $browser->get('http://www.google.com');
- echo $browser->getLastRequest()."\n";
- echo $response;
看起來像是被美化的file_get_contents()，但是它處理所有類型的智能邏輯，並且在后台處理HTTP Response/Request，你也會發現命名空間語法也不是那么的強烈。
真實的世界
目前，大多數PHP存儲依靠主代碼庫。如果你使用Facebook SDK，例如，你僅僅從GitHub或者zip文件中通過復制粘貼的方式把版本推到你的代碼中，然后把它放到你的版本控制系統里面，將會變更。
版本和你的代碼只是作為靜態文件放在里面，在某種意義上，你可能會忘記升級，如果你關注到Facebook已經發布了一個新版本。最新版本文件會顯示在最上面。
使用Composer就無需關注版本變化情況，你只需運行一下更新，那么所有需要更新的都會自動更新。但是為什么還會有大量的代碼在你的倉庫里呢？你不需要它們在那里嗎？
最干脆的做法是添加vendors到你的“Ignore”列表里面（例如gitignore）並且讓你的代碼完全離開那里。當你在部署代碼的時候，你只需運行composer install或者composer update。
如果你想使用更熟練，你可以手動運行整個過程，如果你有雲端托管你可以設置hooks，一旦代碼發布，就運行。
總結
將來，你將會看到更多的Composer，各種豐富多彩的框架已經開始提供了多種層次的集成。FuelPHP將構建Composer包，CodeIgniter提供自動加載並且已經在Symfony2上廣泛使用。
使用Composer添加相關包到你的項目里面是一個很好的方式，無需安裝PECLI擴展或者復制粘貼一個系列文件。那種方式已經很過時了，並且還浪費你大量的時間。（編譯：張紅月）