CHAPTER 12 – DEPENDENCIES
An important benefit of using PEAR is code reuse. However, when you re-use code from a package system, there will be dependencies between packages. These dependencies need to be expressed in the package description to inform users about them.
Element: <deps> Element name: deps Attributes: none May occur in: release (optional) This element is a container for the <dep> element.
Element: <dep> Element name: dep Attributes: name (required) type (required) rel (optional) May occur in: deps (required) The dep element describes a single dependency.
name Attribute This is the target of the dependency. For pkg depen- dencies, the name attribute contains the package name; for ext dependencies, it contains the extension name, and so on.
type Attribute Valid dependency types are php. PHP version dependency; name is ignored. ext. Extension dependency (extension must be installed). pkg. PEAR package dependency. prog. External program dependency; name is the name of program (with- out suffix). ldlib. Build-time library dependency. rtlib. Run-time library dependency. os. Operating system dependency. websrv. Web server dependency. sapi. SAPI backend dependency. Dependency types are described in detail later.
rel Attribute rel is short for relation and tells if and how the ver- sion attribute is compared. Possible values include has. Default. No version comparison; target just needs to be installed/ exist/be true. lt. Installed version must be less than specified. le. Installed version must be less than or equal to specified. gt. Installed version must be greater than specified. ge. Installed version must be greater than or equal to specified. eq. Installed version must be equal to specified. ne. Installed version must be different than specified.
optional Attribute This attribute lets you specify that a depen- dency is not a drop-dead requirement for installing the package, but rather something that would provide enhanced functionality. You may leave it out, or give it the value yes or no.
Dependency Types The PEAR Installer supports different types of dependencies. A package may require another package, that some PHP extension is available, a specific operating system and so on. This is expressed with the following dependency types.
PHP Dependencies PHP dependencies express what version of PHP the package requires. It is good practice to be conservative about PHP version dependencies. If you release the package to a lot of people (such as through pear.php.net), there will always be some PHP upgrade lag among your package's potential users. If you require bleeding-edge PHP, fewer people will be able to use your package.
Extension Dependencies This type of dependency expresses that the package needs a specific PHP extension. During package installation, the installer checks whether the extension is loaded, or if it can be loaded from the default extension directory. If not, the dependency fails.
PEAR Package Dependencies PEAR package dependencies say that this package requires another package. This type of dependency is checked by looking up the PEAR package registry. Because the registry infor- mation is stored inside php_dir, this means that the required package must be installed in the same php_dir as the depending package.
External Program Dependencies When a PEAR package relies on an external program that is not part of PHP or PEAR, this is expressed with an external program dependency. During installation, the installer checks if it can find the required program in the current PATH; if not, the dependency fails.
Operating System Dependencies Most packages run on all operat- ing systems, but some are OS specific, such as the "printer" package. This is specified with an OS dependency.
Reasons to Avoid Dependencies Dependencies are a necessary mechanism for expressing that Package A requires B to function. Although reuse through components is a good practice in theory, it comes at the risk of creating run-way dependencies. These depen- dencies are not literally out of control, but they aggregate more dependencies than intended or reasonable. So, what is the problem with that? Aren't dependencies taken care of by the installer? Yes, but managing dependencies can become time-consuming and complex. If badly managed, complex dependencies will eventually require more time spent managing dependencies and builds than time spent on devel- opment. Often, the biggest motivation for re-use is saving development time, but if re-use becomes too complex, the economics of re-use suddenly fail, and, in a fit of irony, you would save time writing your own. Use dependencies consciously and wisely. If the difference is just a few lines of code or the fact that some package wraps some PHP extension without offering anything else you need, think twice before adding a dependency. As an example, imagine that Package A has dependencies to Packages B and C, and these have dependencies to Packages D, E, and F, respectively