最近花了一段時間整理 PHP 世界裡的 Package Managers
研究了 PECL, PEAR, PEAR2, Pyrus 的關係，還有 PHP 世界的新星 Composer 的發展。
1. PECL – PHP Extension Community Libray
跟其他三者不同，PECL 管理的並不是 Userland 的 Libraries，而且PHP Core Extension。
換句話說它們是用 C/C++ 而非 PHP 寫成，並且需要 Compile 成 .so 或 .dll 在 php.ini 載入使用。
(根據 Wikipedia PECL 發音為 “pickle”)
安裝 Package： PECL 使用 PEAR Installer 提供的 “pecl” 指令安裝 Package，
系統需要安裝適當的 Compiler 才能成功安裝。
安裝完成後會在整台 Server 啟用 (System-wide)。
使用 Package：修改 php.ini 載入剛 Compile 的 Extension
2. PEAR – PHP Extension and Application Repository
PEAR 是第一代的 PEAR package manager，支援 PHP 5.0 或以上。
試圖提供一個中央管理式的 Package Repository，避免開發者 “Re-invert the wheel”。
PEAR 安裝完成後會在 PHP 的 include_path 加上 PEAR 的安裝目錄。
PEAR 的 Package Installer 就是叫 “pear”
安裝 Package：使用 Package Installer “pear install” 安裝 Package
無特別設定的話 PEAR 會把 Package 安裝給整台 Server 使用 (System-wide)。
(PEAR 為了 Shared-host 後來發展出很殘缺不全的 Local Install，設定過的就知道有多殘缺了)
而且「安裝」 Package 時會針對每台 Server 的 Filesystem 設定 (例如使用 absolute path)，
需要搬動 Server 檔案時 (尤其發生在 Windows > Linux)，常常出現很多奇怪的 Error。
使用 Package： PEAR 並沒有規定 Package 要遵從 PSR-0 Standard，
因此 PEAR 大慨沒有 Autoload 可用，需要手動 include PHP files。
(require 在 Project Directory 不存在的檔案，感覺很怪異)
而且如果 Server 沒有安裝該 Package 就會出現 Fatal Error。
發布 Package: Package 需要遵從 Coding Standard ，並且通過 QA Team 審查後才能上架。
Package 不強制使用 namespace，也不需遵從 PSR Standard。
3. PEAR2 – PHP Extension and Application Repository 2
PEAR2 是 PEAR 的改良版，試圖改進 很多PEAR 的缺點。
同樣為中央集權式管理，但使用性、速度、安全上都有改進。
例如 PEAR 設計時終於考慮到把 Package 安裝在 Project 目錄了。
PEAR2 的 Package Installer 為 Pyrus，除了 PEAR2 的 Repository/Package，
它同時向下兼容 PEAR Repository/Package。
(Pyrus 是 Pear (梨) 品種的拉丁文學名)
安裝 Package：使用 Package Installer “pyrus install” 安裝 Package。
可以簡單設定把 Package 安裝在 Project 目錄，
也禁止了 Package 針對 Server 的 Filesystem 設定，解決了 PEAR 的困擾。
使用 Package： PEAR2 規定 Package 要遵從 PSR-0 Standard，
因此 Class 大多都能透過 Pyrus 自帶的 Autoloader 自動載入。
發布 Package: 不明 (?)，PEAR2 的官方網站相當不完整，感覺像未完成品。
根據 Stackoverflow 會員的回答，大慨會比 PEAR 的嚴格多了。
(PEAR2 Repository 現在的 Package 數量，大約只有 20 個)
Composer 是 PSR-0 標準制定後的產物。
與 PEAR(2) 最大的不同是它的 Default Repository “Packagist” 是開放式管理的，
而且這個 “Repository” 嚴格意義上可能只算 “Directory”，
因為真正的 Source Code 可能保存任何 VCS 上 (SVN, GIT 甚至 GitHub)。
安裝 Package：使用 “composer require” 安裝 Package，Composer 會自動生成 composer.json。
或者手動修改 composer.json 然後執行 “composer update”。
Composer 預設把 Package 安裝在 Project 目錄 (除非指定 global 引數)。
使用 Package： 如果 Package 遵從 PSR-0/PSR-4 Standard，
Composer 能夠使用 Autoloader 自動載入。
比起 PEAR1，Composer 允許每個 Project 使用同一個 Package 不同的版本，
解決了同一台 Server 上不同 Project 需要不同版本 Package 的問題。
而每個 Project 裡的 composer.json 明確定義了dependency 及其版本號，
免除了逐個 Package 安裝，漏掉再裝 Trial-and-error 的痛苦，
(使用 PEAR 漏掉一兩個 Package 的情況不時發生，而且有時會很遲才發現)。
順帶一提，Composer 甚至能 安裝 PEAR/PEAR2 的 Package。
發布 Package: 向 “Packagist” 提交 Package 無需任何審查，
門檻及行政程序上比 PEAR 低得多，
更加符合現時 Open Source 流行快速開發及大量分支的模式。
但這也導致無法確定 Package 是否遵從 PSR 標準了。
(不過知名且常用的 Package 通常最少支援 PSR-0)。
Composer 完全支援 Private Repository，架設也相當簡易 (相比 PEAR Channel)。
這代表開發者/公司的私人 Package 也能夠用 Composer 簡單管理了。
無疑 Composer 已經是 PHP 世界大勢所趨，下一篇介紹 Composer 詳細用法。
參考網站：
Composer: What & Why – http://nelm.io/blog/2011/12/composer-part-1-what-why/
The Fall of PEAR and the Rise of Composer – http://benramsey.com/blog/2013/11/the-fall-of-pear-and-the-rise-of-composer/