Artikelformat

PEAR in the box

Letzte Woche wurde ich vor folgendes Problem gestellt: Kann man auf einem Server mehrere Applikationen installieren, die jeweils eine eigene PEAR Installation besitzen. Also gibt es die Möglichkeit eine PEAR Sandbox zu erstellen. Die Frage konnte nicht direkt beantworten, hat aber mein Interesse geweckt und heute gibt es die Auflösung.

Pear kennt man vor allem von einer Installation bei der die Bibliotheken bspw unter /usr/share/php/ liegen. Dort kann man aus einzelnen Channel Pakete installieren und so auf ein rechhaltiges Angebot von Tools, Algorithmen und Bibliotheken zurückgreifen. Nun möchte man aber mehrere Versionen eines Pear-Packages parallel installieren. Dies kann dann passieren, wenn man zum Beispiel 2 Applikationen installiert hat, die auf verschiedenen Versionen basieren und ein Update Änderungen nach sich ziehen würde, die man aus irgendwelchen Gründen nicht durchführen kann oder darf.

Also möchte man sich für jede Applikation eine Pear Sandbox einrichten, in der genau die Bibliotheken vorhanden sind die benötigt werden. Ein weiterer Vorteil ist, dass man die systemweite Pear-Installation nicht mit speziellen Bibliotheken „zumüllt“.

Zuerst legt man ein Verzeichnis an, in dem die Pear-Bibliotheken gelagert werden sollen. Dort sind auch die Aufrufskripte von den diversen Tools (bspw. phpcs beim CodeSniffer) zu finden. Im Beispiel wird das Verzeichnis pear_lib genutzt. Dieses liegt im Homverzeichnis des Benutzer puser.

$ mkdir pear_lib
$ pear config-create /home/puser/pear_lib/ pear.ini

Es wird nun die Konfigurationsdatei pear.ini erzeugt und die wichtigsten Pear-Verzeichnisse in /home/puser/pear_lib angelegt. Diese Verzeichnisse werden automatisch in der pear.ini hinterlegt. config-create legt in der pear.ini folgenden Inhalt an:

Configuration (channel pear.php.net):
=====================================
Auto-discover new Channels     auto_discover    <not set>
Default Channel                default_channel  pear.php.net
HTTP Proxy Server Address      http_proxy       <not set>
PEAR server [DEPRECATED]       master_server    <not set>
Default Channel Mirror         preferred_mirror <not set>
Remote Configuration File      remote_config    <not set>
PEAR executables directory     bin_dir          /home/puser/pear_lib/pear
PEAR documentation directory   doc_dir          /home/puser/pear_lib/pear/docs
PHP extension directory        ext_dir          /home/puser/pear_lib/pear/ext
PEAR directory                 php_dir          /home/puser/pear_lib/pear/php
PEAR Installer cache directory cache_dir        /home/puser/pear_lib/pear/cache
PEAR configuration file        cfg_dir          /home/puser/pear_lib/pear/cfg
directory
PEAR data directory            data_dir         /home/puser/pear_lib/pear/data
PEAR Installer download        download_dir     /home/puser/pear_lib/pear/download
directory
PHP CLI/CGI binary             php_bin          <not set>
php.ini location               php_ini          <not set>
--program-prefix passed to     php_prefix       <not set>
PHP's ./configure
--program-suffix passed to     php_suffix       <not set>
PHP's ./configure
PEAR Installer temp directory  temp_dir         /home/puser/pear_lib/pear/temp
PEAR test directory            test_dir         /home/puser/pear_lib/pear/tests
PEAR www files directory       www_dir          /home/puser/pear_lib/pear/www
Cache TimeToLive               cache_ttl        <not set>
Preferred Package State        preferred_state  <not set>
Unix file mask                 umask            <not set>
Debug Log Level                verbose          <not set>
PEAR password (for             password         <not set>
maintainers)
Signature Handling Program     sig_bin          <not set>
Signature Key Directory        sig_keydir       <not set>
Signature Key Id               sig_keyid        <not set>
Package Signature Type         sig_type         <not set>
PEAR username (for             username         <not set>
maintainers)
User Configuration File        Filename         /home/puser/pear.ini
System Configuration File      Filename         #no#system#config#
Successfully created default configuration file "/home/puser/pear.ini"

Wichtig ist hierbei zu beachten, dass die pear.ini die systemweite Pear Einstellungen superseeded. Das bedeutet, dass die gesetzten Werte in unserer pear.ini die Originalwerte überschreibt. Also ist der preferred_state bspw. stable obwohl er von uns nicht gesetzt wurde. Die eigentlichen Werte kann man so sehen:

$ pear -c pear.ini config-show

Der Aufruf zeigt auch schon, wie man die pear.ini später nutzt. Um zum Beispiel den CodeSniffer zu finden und in unserem pear_lib-Verzeichnis zu installieren. Sind die Aufrufe:

$ pear -c pear.ini search CodeSniffer
$ pear -c pear.ini install PHP_CodeSniffer

Nach diesen Aufrufen findet man die phpcs Executable im Verzeichnis /home/puser/pear_lib/pear.

Die Applikation, in der wir die PEAR-Bibliotheken nutzen wollen, muss noch entsprechend konfiguriert sein, damit unsere Pear-Klassen auch gefunden werden. Hierfür benutzt man die set_include_path Funktion.

Und schon kann man die Applikation in der eigenen Pear-Sandbox nutzen.

Möchte man noch eine Konfiguration ändern, bspw den preferred_state umsetzen, so lautet der Aufruf:

$ pear -c pear.ini config-set preferred_state beta

5 Kommentare

    • Ist ja interessant. Ist also eine praktische Anwendung der Sandbox. Pear ist eigentlich ziemlich mächtig und es ist fast schade, dass diese Infos relativ unbekannt sind.

  1. Warum kann man PEAR eigentlich nicht als standalone-libary, ohne installation, verwenden? Damit meine ich include und gut.

    Antworten
  2. Naja, du kannst natürlich auch ein Package als tgz-Datei herunterladen und entpacken und anschließend mit include nutzen. Aber dann musst du hoffen, dass die Abhängigkeiten zu anderen Packages von dir aufgelöst werden können. Ebenso die zu verschiedenen Pear-Basisklassen.

    Alles machbar und ich spreche da aus Erfahrung, aber bei jedem Update muss man diese Arbeit erneut investieren. Eine Pear-Sandbox (oder lokale Installation wie King Crunch es nennt) nimmt dir diese Arbeit ab und als Entwickler ist man doch faul – also das gute „faul“.

    Ein weiterer Punkt sind Postinstall-Skripte. Diese werden von Pear automatisch ausgeführt und machen manche Packages erst nutzbar. Dies von Hand nachzuvollziehen ist recht mühsam.

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.