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

二、開啓 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