PHP Package Manager – 從 PEAR 到 Composer

最近花了一段時間整理 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 個)

4. Composer & Packagist

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/

Leave a Reply

Your email address will not be published.