[pago]

Bei pake handelt es sich, wie die Überschrift schon sagt, um ein in PHP (5.3) geschriebenes PHP build tool. Jedenfalls ist das die Hauptaufgabe.

D.h. mit pake ist es möglich, bestimmte Aufgaben zu automatisieren. Packen von PHP Anwendungen als phar, Generierung von PEAR-Paketen, kopieren, löschen, bearbeiten von Dateien/Verzeichnissen, usw.

Außerdem lassen sich mit pake Projekt-bezogene PEAR Installationen durchführen. Dadurch hat man alle Vorteile von PEAR (unkompliziertes installieren & aktualisieren von Klassen-Bibliotheken u.ä.) ohne die Probleme (Projekt A benötigt Version X und Projekt B benötigt Version Y -> unlösbarer Konflikt).

Im wesentlichen ist es also eine PHP-Variante von ant/rake, usw.

Es lässt sich auch leicht als Framework für Kommandozeilen-Anwendungen missbrauchen und kann auch Projekte nach Vorlage erstellen (wobei das noch nicht wirklich ausgereift ist - hab da bislang nur die schnellstmögliche Variante von eingebaut.

Mehr Informationen sind auf der github-Seite:
pago's pake at master - GitHub

Falls jemand sich berufen fühlt, Dinge zu verbessern oder hinzuzufügen, würde ich mich darüber freuen und das gern integrieren. Bei Interesse könnten wir das im Rahmen eines Community-Projekts, aufziehen.

Konkret gibt es folgende offene Aufgaben:
- Windows-Kompatibilität (mein Versuchskaninchen hat's mit dem bei xampp (apachefriends) mitgeliefertem php/pear nicht zum laufen gebracht)
- DOKUMENTATION & Tutorials ;)
- Integration von PHPUnit, SimpleTest[, Lime/2] als einfach zu bedienende API. Fällt ein Test durch, wird der build-Prozess abgebrochen (sofern nicht anders gefordert).
- Plugin-Architektur auf PEAR-Basis (Erweiterungen in ~/.pake/ installieren & aktualisieren können, sowohl für Tasks, als auch für Klassen und Projekt-Vorlagen)
- Konfigurationsdateien mit sfYaml/XML/INI (eventuell ZF_Config-Basis) laden können (Projekt-Lokal & ~/.pake/-basierend)
- Projekt-Templates (z.B. zf-basierend)
- PEAR-API verbessern (definieren von channels & dependencies direkt in der pakefile, automatische Installation von neu hinzugefügten Abhängigkeiten, automatische Aktualisierung von veralterten Abhängigkeiten)
- ftp push
- git Integration

Wie gesagt: Würde mich freuen, wenn ihr's euch mal anschaut und über ein wenig Hilfe freu ich mich dann gleich doppelt. ;)

[robo47]

Baut das auf Home - pake - GitHub auf ?
Also das Build-System das Symfony auch nutzt ?
Oder ist das was komplett anderes nur zufällig mit dem gleichen Namen ?

[pago]

Ich hab mir das 'symfony pake' angesehen (wobei das pake, was symfony benutzt hat, nicht mehr weiterentwickelt wird - dein Link ist'n fork davon) und Teile davon wiederverwendet (die Dateioperationen [z.B. Pake::rm] - hab peinlicherweise den Lizenz-Hinweis vergessen, als ich die von std_tasks.php in die Pake-Klasse geschoben habe). Die PEAR-Geschichte baut auf dem 'pearanha'-Skript auf (da hab ich an den Hinweis gedacht). Mein 'pake' hat aber eine andere Herangehensweise (Verwendung von PHP 5.3 Features (Namespaces, Closures, Lambda)) und bietet langfristig mehr Flexibilität.

Ich wollte erst nen anderen Namen für's Projekt wählen (wegen der Verwechslungsgefahr), aber mangelns Ideen und weil der Name so treffend & kurz ist, hab ich ihn dann doch genommen.

[Sekundentakt]

Hallo Pago,

Dein Projekt klingt interessant.
Ich persönlich höre von solchen Tools das erste mal.

Für mich klingt das nach einem Update Manager für PHP Bibliotheken und ggf. auch ganzen PHP-Programmen.

Könntest Du kurz mal etwas weiter ausholen, was für Erfahrungen man für so ein Projekt mitbringen müsste und den ein oder anderen Link zu Hintergrundinformationen posten?

- Windows-Kompatibilität (mein Versuchskaninchen hat's mit dem bei xampp (apachefriends) mitgeliefertem php/pear nicht zum laufen gebracht)

Wie? Wo? Was?
Windows-Kompatibilität? Rufst Du etwa sehr systemnahe Funktionen wie Socket-Kommandos etc. auf oder was genau meinst du mit der angedeuteten Inkompatibilität?

[pago]

pake kann relativ viele verschiedene Aufgaben erledigen. Zum Beispiel kann man damit sehr einfach ein Phar-Archiv seiner Anwendung erstellen. Phar-Archive sind in etwa vergleichbar mit Javas JAR-Archiven. Man packt alle zu einem Projekt gehörende Dateien zu einem einzelnen, ausführbaren Archiv zusammen. Ich nutze das z.B., um pake selbst auszuliefern. Es wird, neben den beiden Scripts für *nix und Windows, nur eine Datei "pake.phar" ausgeliefert. In dieser Datei befinden sich dann spezielle Versionen der benötigten Bibliotheken (pgs/parser, pgs/util, pgs/cli).

Durch die PEAR-Integration kann ich innerhalb des "lib" Verzeichnisses die Abhängigkeiten automatisch verwalten. Bringe ich eine neue Version von pgs/parser und pgs/util heraus, kann ich diese direkt über ein einfaches "pake pear:upgrade" aktualisieren.

Ein Beispiel-Scenario:
Du arbeitest an zwei Projekten: A und B. Beide benötigen Doctrine und das Zend Framework, allerdings in unterschiedlichen Versionen. A möchte mit den neusten Versionen arbeiten, selbst falls diese noch keine stabilen Versionen sind (Doctrine 2, ZF 1.10). Projekt B jedoch wurde schon vor einem Jahr begonnen und benötigt daher Doctrine 1 und ZF 1.7 oder so.
Würdest du diese Bibliotheken direkt mit PEAR verwalten wollen, würde immer nur ein Projekt funktionsfähig sein, weil beide Projekte die gleiche Version nutzen würden, obwohl sie nicht kompatibel sind.
pake versetzt dich in die Lage, diese Bibliotheken nur für ein bestimmtes Projekt zu installieren. Dadurch kannst du die gewünschte Version selbst bestimmen, alle Abhängigkeiten bequem mit einem "pake pear:update" auf einmal aktualisieren und kannst deine Anwendung mit eben genau diesen Versionen ausliefern.

PEAR selbst wird inzwischen langsam immer intensiver genutzt, weil es dank Pirum - The simple PEAR Channel Server Manager einen einfach zu benutzenden PEAR-Server gibt (eigentlich generiert das nur ein paar statische Dateien, die auf jedem beliebigen Web-Server hochgeladen werden können) und weil Pearfarm:Making it trivially easy to create PEAR packages. und pearhub.org auf die Bildfläche getreten sind.

Ich nutze pake z.B., um automatisch nach neuen Versionen meiner PEAR-Pakete zu suchen, pirum auszuführen (um die neuen PEAR-Server-Informationen aufzunehmen) und das ganze dann anschließend per FTP auf meinen Webspace zu laden. Die pakefile im Git-Repository auf Github pakt pake automatisch zuerst als Phar-Datei und dann als PEAR-Paket.

Für die Nutzung sind PHP-Kenntnisse notwendig und man sollte sich durch die Pake-Klasse durchgearbeitet haben, um die Kommandos zu kennen. Das sollte natürlich möglichst durch eine vernünftige Dokumentation vereinfacht werden.

Lektüre (PEAR):
The Democratisation Of PEAR By Pearfarm and Pearhub (or About Bloody Time!) - Maugrim The Reaper's Blog
Pirum - The simple PEAR Channel Server Manager
whitewashing.de :: Trying a Two Step PEAR/PHAR approach to develop and deploy
whitewashing.de :: Application Lifecycle Management and Deployment with PEAR and PHAR (revisited) *UPDATE* (von hier stammt die Implementation der lokalen PEAR-Installation)

Zur Windows-Kompatibilität:
Im Augenblick wirft pake beim ausführen die Fehlermeldung "pake has not been installed properly". Diese wird ausgegeben, wenn der Bootstrap-Code die Klasse pake\Pake nicht finden konnte. Auf meinem MacBook kann ich dieses Problem nicht reproduzieren, mir ist auch nicht klar, wie das unter Windows passieren soll.
Da die Fehlermeldung ausgegeben wird, wird das Phar-Archive gefunden und sogar geladen. Nur die Klassen darin werden nicht gefunden.

[MrNiceGuy]

Überaus interessant, ich habe da auch zum ersten Mal von gehört, aber ich ziehe es jetzt zumindest in Betracht mir demnächst mal genauer anzuschauen. Gerade für Projekte, die man anderen zur Verfügung stellt scheint es eine deutliche Vereinfachung darzustellen. Vielleicht wäre das ja auch eine Möglichkeit, ganze Frameworks zu bündeln!? Allerdings habe ich mich zur Beantwortung dieser Frage noch nicht genug damit auseinander gesetzt.

[pago]

In der "develop"-branch auf github befindet sich jetzt eine etwas neuere Version, die vorerst noch nicht via pear installierbar ist.
Generell: Die Source-Variante enthält eine "lpake.php"-Datei. Linux/OS X-Nutzer können die sehr bequem als alias in der Konsole definieren (Pfad natürlich anpassen):

alias lpake='php -f ~/Projekte/php/pake/lpake.php --'

Ich hab diese Zeile z.B. in meiner .bashrc und kann so eine lokale (immer aktuelle) pake-Version nutzen.

Die nächste Version wird nicht abwärtskompatibel sein.

Dort sind folgende Änderungen enthalten:
- Windows ist nun unterstützt (Fehler war DIRECTORY_SEPARATOR in Kombination mit Phar-Dateien - dort muss immer "/" verwendet werden)
- Alle Erweiterungsklassen (Phar, LFTP, PEAR) sind im pake\ext-Namespace
- sfYaml wird standardmäßig mitgeliefert
- globale Pake-Tasks haben nun kein "pake:" mehr vorangestellt, sondern einfach nur noch ":" - "pake pake:foo" wird "pake :foo"
- PHPUnit-Unterstützung

Besonders letzteres ist mir sehr wichtig gewesen. Wenn die Tests nicht erfolgreich waren, werden Tasks, die davon abhängen, nicht ausgeführt.
Das ist nützlich, wenn man z.B. verhindern möchte, dass man ein Release erstellt, dass nicht voll funktionsfähig ist.

API-Beispiel:

PHP-Code:

<?php
// die / in Backslashes umändern...
use pake/ext/PHPUnit;

PHPUnit::task('unit-test', 'Run all tests',
    Pake::fileset()
        ->name('*Test.php')
        ->in('test'));

Dafür dreht sich mir beim lesen der Task-Execution nun aber der Kopf um 360°... da wird wohl ein Refactoring notwendig sein - das wird allerdings keine Kompatibilitätsprobleme hervorrufen.

Vielleicht wäre das ja auch eine Möglichkeit, ganze Frameworks zu bündeln!?

Ja, das ist eine der Anwendungsmöglichkeiten. Für die Bibliotheken, von denen pake abhängig ist (pgs/cli, pgs/util, pgs/parser) habe ich jeweils ein Projekt mit einem pakefile. Über dieses pakefile kann ich PEAR-Pakete herstellen und sie in mein öffentliches pear-Repository (pear.pagosoft.com) einspeisen.

PEAR-Pakete, die man ebenfalls mithilfe von pake installieren kann (siehe Doku) gibt es auf pearhub und pearfarm (links siehe oben) und viele Projekte haben ein eigenes PEAR-Repository. Das Zend Framework lässt sich z.B. auch so installieren (allerdings über eine inoffizielle Repository - AFAIK).

[pago]

Die neue Version ist wieder eine "beta"-Version, da die Tasks relativ stark erweitert wurden und für diese Klassen noch keine Tests existieren.
Erst-Installation (nach channel-discover):

pear install pgs/pake-beta

Upgrade:

pear upgrade pgs/pake-beta

Neu und verbessert in Version 0.7 (die größeren Sachen):

PEAR-Dependency-Management
pake kann nun Abhängigkeiten installieren und deinstallieren. Ein Beispiel aus pake's eigener pakefile:

PHP-Code:

Pake::task('sync-pear', 'install/remove channels and packages')
    ->run(function() {
        Pake::dependencies()->in('lib')
            ->fromChannel('pear.pagosoft.com')
                ->package('util')
                ->package('cli')
                ->package('parser')
            ->fromChannel('pear.php-tools.net')
                ->package('vfsstream', 'alpha')
            ->fromChannel('pear.symfony-project.com')
                ->package('yaml')
            ->sync();
    }); 


Wenn ich dort nun ein Paket oder einen Channel hinzufüge/entferne wird das automatisch umgesetzt. Besonders praktisch bei neuen Projekten.

pakeBundles
pake fügt ein lokales ~/.pake-Verzeichnis (sofern es existiert) zum include_path hinzu. So können in pakefiles häufig benutzte Bibliotheken (z.B. das Zend-Framework, bzw. Teile davon) eingebunden werden. Außerdem werden alle phar-Dateien automatisch geladen. Mithilfe von pake ake-bundle-project mybundle lässt sich bequem ein neues Projekt erzeugen, dass eine pakefile zum packen von Bibliotheken enthält. Diese phar-Dateien können mithilfe von require_once 'mybundle.phar'; eingebunden werden und stellen alle mitgelieferten Klassen via autoload zur Verfügung. Außerdem enthält die pakefile einen install-Task, der die Bibliothek automatisch als pake-Erweiterung installiert.

pirum Integration
Sofern pirum installiert ist, kann nun über eine bequeme API ein neues Release zur bestehenden pirum-repository hinzugefügt werden:

PHP-Code:

Pake::task('publish', 'Publish the pear package on pear channel')
    ->dependsOn('dist')
    ->run(function() {
        Pirum::onChannel(Pake::property('pear.dir'))
            ->addLatestVersion('dist');
    }); 


Dazu ist fast der komplette Kern neu geschrieben worden. Die alte Version war einfach für die neuen Features (im Speziellen PHPUnit) zu unflexibel und hat sich mehrfach im Kreis gedreht. Die neue Version hat eine stärkere Aufteilung in einzelne Komponenten und nutzt Dependency Injection um flexibler und testbarer zu werden.

Mit diesem Release ist der Großteil meiner Liste abgearbeitet und mein nächstes Ziel ist die Dokumentation. Wenn alles nach Plan läuft, werde ich diese in Form eines ebooks veröffentlichen - allerdings in Englisch. Wer in der Zwischenzeit mithelfen möchte: Ich würde mich wirklich sehr über Tutorials und Beispiele freuen. Auch falls sich jemand berufen fühlt, die SimpleTest-Integration vorzunehmen wäre das toll.

[Neq']

Hab ich heute zufällig beim surfen entdeckt: jaz303's phake at master - GitHub

[pago]

Das witzige dabei ist, dass ich das Projekt ursprünglich als "phake" angefangen habe und dann alles nach "pake" umbenannt habe. :)

Dieses "phake" ist im Prinzip meinem pake recht ähnlich, hat aber doch einen anderen Ansatz. Mir gefällt die implizite Zuordnung von desc->task in der Form nicht. Spätestens wenn man anfängt, Parameter und Argumente zu erlauben (so wie pake das tut), ist der Ansatz stark limitiert.

Was mich zum Nachdenken bringt ist das Group-Feature. Ich hab im Kopf, dass das cool wäre, allerdings sehe ich insgesamt nur stark begrenzten Nutzen. Vielleicht in der Form, dass man eine Menge von Tasks als ein einzelner ansprechen kann, wobei das durch die Abhängigkeiten gut genug umgesetzt sein sollte. Hmm... muss ich mal drüber schlafen (Diskussion dazu ist erwünscht).

Als Ankündigung: Ich hab gestern bemerkt, dass das aktuelle Release von pake nicht ordentlich funktioniert. Im Speziellen geht es da um die PEAR-Funktionen. Das war mir vorher nicht aufgefallen, weil ich im Prinzip immer "lpake" verwende (also die lokale Entwicklungsversion). Ich hab den Fehler aufspüren können und als Ergebnis wird die nächste Version nicht mehr als phar-Datei ausgeliefert. Mir ist die Lust, ständig irgendwelche Bugs zu jagen, die durch das packen als phar entstehen, vergangen.

Ein neues funktionierendes Release wird vermutlich morgen als 0.7.1 erscheinen. Ich möchte vorher noch die neuen Funktionen zum packen von PEAR-Paketen als API einbauen und einige Tests ergänzen und die Github-README mal aktualisieren.

[robo47]

Ich denke sobald ich mal komplett richtung php 5.3 wechsel werde ich mir das ganze mal genauer anschauen, aktuell bin ich froh dass mein build und deploy-prozess über ant läuft und ich mit hudson ne schöne CI-Umgebung habe wo das alles (phpcs, phpcpd, pdepend, phplint, doxygen, phpunit ... ) läuft.
Aber da mein Produktiv-System sowie die CI-Umgebung noch komplett mit php 5.2.X läuft kann ich das aktuell noch nicht wirklich testen.