太陽底下沒有新鮮事

Simpler to use than PEAR  (使用比pear簡單)

Pyrus is distributed as a single file, pyrus.phar. Because of PHP's new phar extension^(註1), Pyrus does not need to be installed, and can run directly from the file pyrus.phar.

(pyrus是分散式的如同單一檔案一樣，pyrus.phar，因為新的phar extension^(註1)關係， pyrus是不需要被安裝的，直接就可以被pyrus.phar來執行)

Pyrus also simplifies the command-line options available, and provides a far greater range of developer tools for creating, managing and distributing packages through tools such as the simple channel server and package.xml creation command make.

(pyrus也簡化可用的命令列選項，而且提供給建立、管理和發佈套件的發展工具更好又更大的彈性，透過一些工具像是simple channel server和package.xml creation 命令來建立。)

(註1：

The phar extension provides a way to put entire PHP applications into a single file called a "phar"

The phar extension提供一個的方法將整個php的應用程式放到一個單一的檔案，稱作"phar"

)

More secure than PEAR (比pear安全)

Several security vulnerabilities in the design of PEAR were discovered due to the particular Command Pattern implementation used to detect file roles, commands, and other plugins. Pyrus fixes this by requiring that all plugins be installed into a centralized location separate from the actual PEAR installation. In addition, installation of plugins cannot happen at the same time as installation of packages, thus the enforced separation ensures a level of security that is much higher than PEAR supports, while preserving the flexibility that extending the installer provides.

(由於個別的命令模型實作過去習慣會去偵測檔案規則、命令和其它的外掛，幾個安全的漏洞在pear設計時被發現出來。pyrus修復這些漏洞藉由要求所有的套件集中安裝在一個地方，並從實際的pear安裝中分離出來。除此之外，套件的安裝不能發生在同一個時間例如套件的安裝，所以強迫分離會確保比pear所提供的還要來得高的安全層級，反之保留了延伸案裝程式提供的彈性。)

Pyrus also feaures true package signing and signature verification using OpenSSL PKCS#12 and X.509 certificates. This allows users to directly verify the validity of a package, protecting from man-in-the-middle attacks and other potential disruptions of a package release. This feature requires the openssl extension, which is not enabled by default.

(pyrus 使用OpenSSL PKCS#12和X.509來做為套件的可靠認證。這是用來允許使用者直接驗證一個套件的有效性，保護不受中間者攻撃和其它潛在性的套件瓦解。這些特色預設是沒有開啟的，需要openssl的延伸)

PEAR supports signing packages using PGP keys, but has no mechanism in place to verify the signed packages. Pyrus will refuse to install a signed package without verifying the signature even if the openssl extension is not enabled.

(pear有提供PGP keys來提供套件簽署，但是沒有理論來提供驗證。儘管pyrus預設的openss extension預設是沒有開啟的，但pyrus還是會拒絕安裝任何沒有經過驗證的套件。)

In addition, the new paranoia setting can be used to control how upgrades are performed to releases that change the API, helping to guarantee safe upgrades to future releases.

(此外，新的paranoia設定可以用來執行和控制更新釋出的API套件，協助並保證未來釋出版本的更新和安全。)

Smaller than PEAR (比pear還小)

Because Pyrus takes advantage of PHP 5.3's built in support for XML processing, archive handling, and advanced structures through the simplexml, libxml2, phar, sqlite3, and spl extensions, Pyrus is significantly smaller than PEAR, and as a result consumes far less memory to accomplish its tasks.

(因為pyrus是採取php 5.3建立在XML處理、檔案操作和透過simplexml、libxml2、phar、sqlite3和spl 延伸結構上的優點，所以pyrus明顯上會比pear小, 因此完成一件工作時所消耗的記憶體會比較少。)

Faster than PEAR (比pear快)

Pyrus is also faster than PEAR because of its reliance on built-in features of PHP 5.3 and a more structured object-oriented design.

(pyrus也比pear快，因為它依賴建立在PHP 5.3的特色和一個多結構的物件導向設計)

More robust than PEAR (比pear強健)

Pyrus has redundant registries in XML and Sqlite3 database formats, as well as support for the existing PEAR registry. Reconstruction of a corrupted registry is simple and fully supported.

(pyrus 有多餘的註冊在XML和Sqlite3 資料格式上，也提供已存在的pear註冊。簡單和完整的提供改造損壞的註冊。)

(這段翻的也怪怪的說 @@)

In addition, all installation tasks occur within an atomic transaction, including file installation and removal, so that if an installation or uninstall command fails mid-stream, or something as drastic as a power failure occurs, the PEAR installation will be not be left in a half-installed state.

(此外，所有安裝任務進行在一個極小的處理內，包含檔案的安裝和搬移，因此，假如一個安裝或反安裝命令在中間運作時失敗或是一些非常嚴重的像是電源故障之類的發生，pear是不會在安裝一半的時候離開)

(各位客倌會不會覺得這段怪怪的呀… ^^")

More flexible than PEAR (比pear更靈活)

Pyrus supports cascading installations, so that a system-wide installation of core packages can be recognized. By default, include_path is used to detect PEAR installations, but a different location for a PEAR installation can be passed directly to Pyrus as its first argument.

(pyrus 提供一連串的安裝，所以安裝全部核心元件是可以被認可的一個方式。藉由預設，include_path是習慣用來檢測pear安裝,但是一個不同地點的安裝對於pear來說，可能會直接被傳遞到pyrus來當作一是第一個參數。)

Convention over configuration allows packages constructed with the new PEAR2 coding standards to be installed simply by extracting the archive, and then later upgraded using Pyrus without the intermediate step of using Pyrus to install the packages. For the first time, this allows a try-before-you-buy approach to be possible.

(協定超過規定允許套件建立新的pear2編碼標準，簡單的經由提取檔案來安裝，然後在更新之後使用沒有媒介的pyrus去安裝套件。首先這是允許在你買之前先試的可能的方法)

(這一段大爺看不太懂耶…不知道有沒有好心的官倌可以幫大爺翻譯的呀 ^^")

The same principle also makes bundling a PEAR2 package in another package's source repository possible, and Pyrus can be used to easily upgrade the package or revert to a previous version.

(相同的原理也讓打包一個pear2套件在其它套件的來源程式庫成為可能，而且pyrus也容昜的使用來更新套件或恢復到先前的版本)

More tested than PEAR (比pear多測試)

Pyrus has been developed with extensive unit testing and xdebug^(註2) coverage data has been used to verify that the code is being executed. As a result, the first alpha release of Pyrus has 10% higher code coverage than the most recent stable version of the PEAR Installer.

(pyrus已經發展有著廣泛的單位測試和xdebug 有效範圍的資料已經使用來驗證正在執行中的程式碼。因此，pyrus的第一個alpha版本的程式碼範高於目前最新穩定版的pear安裝程式10%。)

(註2：The Xdebug extension helps you debugging your script by providing a lot of valuable debug information.

Xdebug藉由提供許多有用的除錯資訊來幫助你找出你的script錯誤)

)

One of the most important conceptual changes in Pyrus is how configuration is handled. PEAR was designed to handle at most 2 installations by default, a system and a user PEAR installation, and it excels at this. As soon as PEAR is used on multiple installations, a separate configuration file must be specified (as in pear -c /path/to/another/pear.conf install blah). This leads to what is colloquially referred to as "config hell", where it is easy to accidentally install things into the wrong place without realizing it. Pyrus's configuration handling is specifically engineered to eliminate config hell, and to make handling multiple PEAR installations simple.

(在pyrus上很重要的觀念轉變是設定檔如何被處理。pear過去原始的設計是處理不超過2個安裝程式，一個是系統檔和一個是使用者的pear裝置。而且這是它的優點。pear一使用在多重安裝的話，一個分開的設定檔就必須被定義(像是在 pear -c /path/to/another/pear.conf install blah).這就會導致出在口語上稱作是「配置上的鬼東西」，而且容昜意外地安裝一些東西到並不清楚的錯誤的地方。pyrus的設定管理就是特定地設計來處理這些「配置上的鬼東西」，而且很簡單的處理多重的pear安裝。)

PEAR stores all configuration values in a single configuration file, and allows specifying a different configuration file for different setups. In addition, PEAR supports automatic cascade of a system configuration file and a user configuration file. The configuration values are used when installing applications, and for customizing things like the path to php in the PEAR Installer's pear command. Configuration files are stored separate from the PEAR installations that they represent.

(pear 儲存所有的設定值在一個單一的設定檔內，而且允許定義不同的設定在不同的設定檔中。此外，pear提供一個系統設定檔和一個使用者設定檔的自動串連。設定值用來當安裝應用程式和自定一些東西像是設定在php內的一些pear 安裝的指令。設定檔也分別儲存pear安裝程式的描敘。)

Pyrus instead splits up configuration files into two separate components: one file contains user customizations such as the preferred stability of packages to install, the username and password for logging into a channel, the verbose setting and so on. Configuration variables that affect where to install files are stored in a separate configuration that is tightly bound to the PEAR installation.

(pyrus而是分開配置到2個不同的元件中;一個檔案包含著使用者的定義像是優先安裝的一些穩定套件，登入至channel的使用者帳號和密碼，詳敘的設定等等。設定值內的變數會影響安裝檔被儲存在一個單獨的和pear安裝程式有很大關聯的設定檔之中。)

Thus, a PEAR configuration setup might look like:

(因此，一個pear設定檔的設定看起來會像是這樣：)

• System configuration in /etc/pear.conf, defines php_dir as /usr/local/lib/php

• User configuration in /home/username/.pearrc, defines php_dir as /home/username/pear.

• include_path is set to /home/username/pear:/usr/local/lib/php.

The equivalent configuration setup with Pyrus would look like:

(而包含pyrus的相同設定檔會看起來像這樣：)

• Pyrus-based installation in /usr/local/lib/pear, system configuration stored in /usr/local/pear/.config and php files in /usr/local/lib/pear/php.

• Another Pyrus-based installation in /home/username/pear, system configuration stored in /home/username/pear/.config and php files in /home/username/pear/php.

• User configuration in /home/username/.pear/pearconfig.xml.

• include_path is set to /home/username/pear:/usr/local/lib/pear/php.

By default, Pyrus uses the include_path to locate PEAR installations, but this is configurable with the new user configuration variable my_pear_path, which is a PATH_SEPARATOR separated list of paths to PEAR installations.

(預設上，pyrus使用include_path去設定pear安裝程式，但這是與包含新的使用者設定變數my_pear_path一起配置，這個使用者設定變數是一個PATH_SEPARATOR分開的pear安裝程式的路徑的目錄。)

In addition, an explicit path can be directly passed to Pyrus:

(此外，一個外部的路徑可以直接被傳遞到pyrus：)

php pyrus.phar /home/username/pear:/usr/local/lib/pear list-packages

The above command will list the installed packages in both registries in /home/username/pear and in /usr/local/lib/pear/php.

(上面的命令將會列在2個安裝套件的登錄檔中，一個是 /home/username/pear，另一個是 /usr/local/lib/pear/php。)

A detailed reference of Pyrus's handling of configuration files is here

(更詳細的pyrus設定檔管理可以參考這裡)

Pyrus fully supports PEAR's registry format, but introduces 2 new registry formats, an sqlite3 database-based registry, and an XML file-based registry. These registries are fully redundant, and can be used to repair or reconstruct a corrupt registry.

(pyrus 完全的支援pear的登錄格式，不過這邊要再介紹2個新的登錄格式，一個是sqlite3資料庫基礎的登錄，另一個是xml檔案基礎的登錄格式。這些登錄檔完全是多餘的，而且可以被使用在修理或是重建一個毀壞的登錄檔。)

In addition, unlike PEAR, which stores the registry in the same directory as the PHP source files, Pyrus stores the registry in its parent directory. Thus, PHP files stored in /usr/local/lib/php have their registry in /usr/local/lib.

(此外，不像pear一樣儲存登錄檔在相同的像是php來源檔的資料夾中，pyrus儲存這些登錄檔在它的根資料夾中。因此，php檔案儲存在 /usr/local/lib/php, 而它們的登錄檔在/usr/local/lib裡。)

For backwards compatibility, an older PEAR registry is always stored in the location the PEAR Installer expects it to be stored.

(為了向下相容的關係，所以一個舊的pear登錄檔會一直儲存在pear安裝檔預設被儲存的位置。)

Pyrus is intelligent enough to detect which registries are present, and to use them. If only an older PEAR registry exists, Pyrus will not automatically upgrade to the newer format. However, the upgrade-registries command is available to convert from an older registry to the newer format.

(pyrus很聰明的會自已決定那一個登錄檔要被顯示和使用。假設只有一個舊的pear登錄檔存在，pyrus將不會自動更新到新版的格式。因此，upgrade-registries這個命令可以將舊的登錄檔格式轉換到新版的格式。)

Some of the benefits of the newer registry format include much speedier processing of a large registry at installation time due to Sqlite3's speedy processing. Additionally, truly safe uninstall-time resolution of dependencies is possible, something that PEAR can only do for relatively simple package dependency trees.

(因為 Sqlite3的高速處理，有一些較新的登錄格式可以更快速的安裝大型的登錄檔案，此外，真正安全的卸載時間相依性的解決是可行的，pear可以只做一些比較簡單的套件相依樹。)

In addition, the XML registry consists of storing the package.xml and channel.xml files for package releases in the same location that they are packaged. This is what makes it possible to extract a package created with Pyrus and then later use Pyrus to upgrade it.

(此外，XML登錄檔在套件被打包釋出時會在相同的地方儲存含有package.xml和channel.xm這兩個檔案。這也是讓pyrus可以取出由pyrus建立的套件而且之後還可以用pyrus來更新。)

For instance, the hypothetical PEAR2_Foo package from channel pear2.php.net version 1.2.3 will store its package.xml in path .xmlregistry/packages/pear2.php.net/PEAR2_Foo/1.2.3-package.xml inside the archive, so that when it is extracted, it lines up exactly with how the package would look on disk when installed with the XML registry.

(給個例子，假設pear2_foo 從channel pear2.php.net version 1.2.3打包會儲存它的package.xm在.xmlregistry/packages/pear2.php.net/PEAR2_Foo/1.2.3-package.xml這個路徑的檔案裡，所以當它被讀取時，它會正確的排列就像是安裝XML登錄檔時套件在硬碟中的樣子。)

Pyrus no longer supports package.xml version 1.0, although it will include a package.xml version 1.0 in an archive designed to support both earlier PEAR versions and the more recent versions. It does not validate the package.xml, however, and so it is important to validate any older package.xml format using PEAR and not Pyrus.

(pyrus 不再支援 package.xml version 1.0，雖然它還會包含一個 package.xml version 1.0的檔案在檔案設計中，以支援早期和目前的版本。不再驗證package.xml，因此，很重要的一點是驗證任何舊的package.xml格式應該使用pear而不是使用pyrus。)

In addition, Pyrus has introduced support for PEAR2 packages that can be extracted to disk and then later upgraded using Pyrus. To implement this feature, Pyrus transforms paths in a different way from PEAR.

(除此之外，先前已介紹pyrus支援從硬碟讀取pear2 套件而且之後還能使用pyrus來更新。為了實作這項功能，pyrus從pear用一個不同的方式來轉換路徑。)

For example, this entry from a package.xml:

(看個例子，這個是包含在package.xm裡面的內容)

   <dir name="php" baseinstalldir="PEAR2">
    <dir name="Pyrus">
     <dir name="Developer">
      <dir name="CoverageAnalyzer">
       <dir name="SourceFile">
        <file role="php" name="PerTest.php"/>
       </dir>
      </dir>
     </dir>
    </dir>
   </dir>

would cause PEAR to install PerTest.php into the relative path PEAR2/php/Pyrus/Developer/CoverageAnalyzer/SourceFile/PerTest.php. Pyrus, however, recognizes that php is actually the default value of the php_dir system configuration variable, and strips it from the path, resulting in PerTest.php being installed into the path: PEAR2/Pyrus/Developer/CoverageAnalyzer/SourceFile/PerTest.php.

(而這應該會產生pear安裝PerTest.php在和pear2有關的路徑裡/php/Pyrus/Developer/CoverageAnalyzer/SourceFile/PerTest.php。然而，pyrus認為php實際上是php_dir系統設定變數的預設值，並且會將它從路徑上移除，結果安裝在PEAR2/Pyrus/Developer/CoverageAnalyzer/SourceFile/PerTest.php. 這個路徑的PerTest.php這個檔案中。)

To enable this handling, one need only set the <pearinstaller> dependency to version 2.0.0a1 or newer. Pyrus will automatically recognize any package.xml with a <pearinstaller> dependency on any version of the PEAR Installer as an older package.xml, and will not perform the magic removal of configuration values from directories.

(要開啟這個功能，一個必要的步驟是僅僅設定<pearinstaller>相依性到版本2.0.0a1或更新版。pyrus將會自動地識別出任何pear安裝程式中含有 <pearinstaller>相依性的任何package.xml的檔案，像是舊版的package.xml檔，而且不會執行神奇的從目錄中移動的設定值。)

No other changes have been made to package.xml handling, except that the default version of package.xml used when generating a package.xml is version 2.1, which has been supported by the PEAR Installer since version 1.5.0.

(沒有其它的改變已經讓package.xml處理，除了當產生一個2.1版本的package.xml，預設的package.xml的版本被使用之外，從版本1.5.0開始就已經被支援了)

(這一段非常怪…大爺看不太懂說 @@…有沒有客倌可以為大爺指點一下迷津啊 = =")

The PEAR Installer allowed packages to install custom commands as well as custom file roles and custom file tasks that are used in package.xml. Pyrus also allows this, but the format of plugins is very different. If you are simply a user of PEAR, you probably won't notice the difference, except that some packages that use custom file roles or tasks will not be installable by Pyrus until the maintainer releases an update that will work with both PEAR and Pyrus.

(pear安裝程式允許套件去安裝自訂的命令以及自定的檔案規則和被使用在package.xml的檔案工作。pyrus也允許這些，只是使用的外掛格式是完全不同的。如果你是很一般的pear使用者，那麼對你來說應該沒有太大的影響，除了一些使用自定規則或工作的套件將沒辨法被pyrus安裝直到開發者釋出可以在pear和pyrus上運作的更新版。)

PEAR extensions are installed directly into the location where the PEAR installer is located. Thus, if PEAR is located in /usr/local/lib/php/PEAR, a custom command must install its XML information file and PHP script into /usr/local/lib/php/PEAR/Command, a custom file role must install its XML information file and PHP script into /usr/local/lib/php/PEAR/Installer/Role and a custom file task must install its PHP script into /usr/local/lib/php/PEAR/Task.

(pear延伸程式會被直接安裝在pear原本安裝的地方。因此，假如pear是安裝在/usr/local/lib/php/PEAR，那麼「自定的命令」須要安裝它的xml資訊檔和PHP script檔到/usr/local/lib/php/PEAR/Command裡，「自定的檔案規則」要安裝它的XML資訊檔和PHP script檔到/usr/local/lib/php/PEAR/Installer/Role裡而「自定的檔案任務」必須安裝它的PHP script到 /usr/local/lib/php/PEAR/Task裡。)

Pyrus is distributed as a phar archive, so this model is no longer physically possible, one cannot just magically insert files into the phar archive without considerable pain and annoyance (the phar.readonly INI setting must be disabled by hand). Instead, Pyrus installs all plugins into a location specified by the new plugins_dir user configuration variable. By default, this installs plugins into $HOME/.pear/plugins on unix systems, and My Documents\pear\plugins on Windows.

(pyrus 被分配像是一個phar檔，所以這個模式是不復實際的可能，在沒有重要的計劃和煩腦不能只是很神奇的附加檔案到phar檔裡{phar.readonly INI 設定經由處理必預被取消}。作為代替，pyrus安裝所有的外掛到一個由新的plugins_dir 使用者設定變數所指定的位址。預設上，linux的外掛會安裝在$HOME/.pear/plugins，而windows會安裝在My Documents\pear\plugins。)

All plugins to Pyrus now must provide an xml file with one of the three new file roles customcommand, customrole or customtask in package.xml. Pyrus uses the information in the XML file to locate the PHP script that will execute the plugin. In addition, only one plugin is allowed per package, and the first one Pyrus encounters is the one that will be used. More information on custom plugins is provided in the Pyrus plugins section of the manual.

(所有到pyrus的外掛現在必須提供一個xml檔案，這個xml檔案需含有三個新的檔案規則customcommand、customrole或是customtask其中的一個在package.xml裡。pyrus使用這個資訊在XML檔案中，去指定將會執行外掛的PHP script。此外，只有一個外掛是被許可的每一個套件，而且第一個pyrus所遇到的是會被使用的一個。自定外掛的許多資訊會說明在pyrus plugins 這個使用手冊的章節內。)

For developers of existing PEAR custom roles/tasks and post-install scripts, a special kind of file role that allows configuration of your package after installation, making your work compatible with Pyrus can be accomplished. See the documentation on Custom Roles, Custom Tasks, and Post-install scripts.

(為了讓存在的pear的開發者自定規則/任務和 post-install scripts，一個特別的檔案規則的種類允許定義你的套件在安裝之後，讓你的工作能與pyrus相容，能夠被完成。相關的資訊請參考這些文件 Custom Roles, Custom Tasks, and Post-install scripts.)

PEAR's handling of PECL extensions has been somewhat dodgy, with reports of issues with phpize failing, and other problems. Pyrus attempts to fix this through two major changes to the way PECL packages are built and installed.

(pear的 PECL延伸處理已經有點危險，有些發表報告包含有phpize錯誤的和其它問題。pyrus 嘗試去修理這些問題透過2個主要改變pecl套件的建立和安裝的方法。)

1. PECL packages are installed into a new location src/ and then built directly inside this location. (PECL套件安裝到新的路徑 src/，然後直接建立內部的這個路徑)

2. The same tool process used to build extensions by hand is used verbatim by pyrus to build the extension

     
phpize --clean
phpize
./configure [any options specified by <configureoptions>]
make
make install