Last Modified 2019-05-02 by Guest

No More Pear: Move to composer

Remove any hard runtime or installation dependency on pear and pearisms


List any tickets on http://bugs.horde.org/ that cover this issue or are relevant to it.


Ralf Lang


The PHP ecosystem has increasingly moved from pear to composer as the default installer. The changed paradigm (global versus local dependency management) attracts many users and developers.

Runtime dependencies

horde-db-migrate and web migrator

horde-db-migrate "forgets" to migrate or even acknowledge libraries in git checkouts where the pear channel is not present.

l10n/translation tools?

Document .horde.yml format and how it relates to composer json and pear xml

TODO: beautify, break out to separate page

id: string, mandatory, uppercase and minus Horde_ for libs, lowercase for apps (horde, turba, Autoloader, Exception)
name: string, mandatory, Uppercase (Horde, Turba, Autoloader, Exception)
full: string, mandatory, a one-line description
description: string, mandatory, a multi-line description
list: string, mandatory, may be empty: a hint on the mailing list appropriate for the component
type: string, mandatory, either "application" or "library"
homepage: string, mandatory, a related informational url
authors: list, each element has string attributes name, user, email, active (true/false), role (lead, developer)
version: has sub keys api and release each with a version string (1.0.0 format)
state: has sub keys api and release, each with a stabilitiy string (stable, beta, alpha)
license: has subkeys identifier and uri
license: identifier: An SPDX license identifier string
license: uri: a link to a fulltext license
dependencies: top level structure for several optional keys
dependencies: required: multilevel list of mandatory dependencies (php, pear, ext) - The key and all sub keys are optional
dependencies: required: php: optional key. The value should be a version constraint string
dependencies: required: pear: optional key. This is a list of channel/package keys and version constraint values. For pecl extensions, there may be additional sub keys instead of a version string
dependencies: required: ext: optional key. This is a list of php binary extensions (hash, pdo, ...) as keys and version constraint strings as values.
dependencies: optional: multilevel list of optional, suggested collaborators (pear, ext) - The key and all sub keys are optional
dependencies: required: pear: optional key. This is a list of channel/package keys and version constraint values. For pecl extensions, there may be

Suggested additions to the format

I suggest to add an optional top level key "autoload", inspired by corresponding composer.yml strucute
It hints how autoloaders should expect to find php classes from the package.
Structure would be
autoload: psr-0: list of "Class_Prefix" : "dir"
autoload: psr-4: list of "\\Prefix" : "dir"
autoload: map: list of directories to recursively scan for php files containing classes

The default if absent would be equivalent to psr-0: "Horde_Foo": /Lib


Generate composer json file from .horde.yml

components/lib/Helper/Composer.php currently depends on conductor and gets its data from package.xml
anything handling package.xml is broken without pear though. Always need to register the horde channel

rewrite all pear.horde.org dependencies to vcs type dependencies github/horde/


Other resources
Do we want to keep a whitelist of other channels/packages which should be pulled from packagist or github rather than pear?

Composer plugin: install apps below base rather than vendor/

(we don't want /vendor/ web-readable)
horde apps are type "horde-application" and get installed to /$appname or base/appname
Installing/updating an app should clear cache and autoloader cache
Check if the app provides a registry snippet in /doc/
write horde.local.php if necessary
installing base should provide some initialization

Composer plugin: copy, move or link js content from libraries to horde/js

horde libs are type "horde-library" and get installed to /vendor/Horde/Foo
Maybe we find some trick


Add tool chain to create and update packages on packagist for easier consumption.

Autoloading and fixed loading

Examining horde base bootstrapping:

horde/horde/index.php require_once lib/Application
Horde/Application.php require_once core.php
core.php checks for horde.local.php -- possible to announce a composer setup here
Either include_once Horde/Autoloader/Cache.php or require_once Horde/Autoloader/Default.php

Examining nag bootstrapping:

horde/nag/index.php and other client pages require_once nag/lib/Application.php
nag probes for horde_dir (either info from horde.local.php or directory above nag dir)
finally load (hordedir)/lib/core.php

-> both in base and apps, we can edit horde.local.php for hinting and autoloader ultimately comes from horde/lib/core.php

Issues with Horde_Autoloader_Default and Horde_Autoloader_Cache

Horde_Autoloader_Default has unconditional require_onces
Horde_Autoloader_Default registers unconditionally when loaded
Horde_Autoloader_Cache requires/registers Horde_Autoloader_Default unconditionally

Examining git-tools as a composer-native app:

git-tools binary detects the composer autoloader entrypoint vendor/autoload.php and require_once it.
the composer autoloader is configured to provide a psr-4 autoloader for the \\Horde\\GitTools namespace to ./lib

PSR-0, db migrations, classmaps and packages

Most horde library packages are simple to map to the psr-0 autoloader.
Package Horde_Foo would have all its classes in lib/Horde/Foo.

Some packages though have class names you would not expect from the package name
Horde_Core has Horde_ErrorHandler & friends
Horde_Form has multiple classes in one file
Horde_Util has Horde_String

These either need to be scanned for additional mappings or need "classmap" style autoload hints.
Unit tests should be marked as autoload-dev (root package only autoloads)
migrations should be autodetected by the composer writer. (TODO: simply auto-add a classmap?)

special case classmaps should be hinted by .horde.yml


Horde_Test bundles phpunit. A Horde Library uses a copy of boilerplate code from horde_test to initialize autoloading. This boilerplate makes some PEARish assumptions (universal include hierarchy)

This pull request offers a new template and fixes other unconditional require_once instances https://github.com/horde/Test/pull/1
This should hopefully work for PEAR installs, composer installs and full git checkouts just the same.

Proof of concept

There is a proof of concept in https://github.com/maintaina-com
This proof of concept includes all software patches which are part of this effort

components and git-tools

In this project, the components tool is used via git-tools as a frontend
Various patches have been applied. Most relevant is a rewrite of the Components_Helper_Composer class.

This class now writes a thoroughly different composer file than before and it takes its data from horde.yml
rather than package.xml

config options govern
- if we want to build against dev-master dependencies or dependencies using the horde.yml version constraints
- if we assume all packages live on packagist, in a shared satis repo or a per-library git location
- how to translate non-horde pear dependencies into packagist dependencies (otherwise, pear channels will be used)

Core, Base and Autoloader

Several patches were needed in places where horde just assumed files to always be in a certain location.
Most of these patches SHOULD NOT break git dev installs or pear installs - testing was very limited

Other relevant changes were detection of migration files in Horde_Core_Db_Migration and handling of Horde_Controller routes in


The Horde_Test suite had some hardcoded requires which were made condidional.

Other libraries

Unmentioned libraries SHOULD only have been modified by replacing the master branch composer file


https://getcomposer.org/doc/articles/custom-installers.md composer notes on custom installers and plugins
https://github.com/composer/installers multi-framework collection of installers

Back to the Project List