Ergebnis 1 bis 17 von 17

Thema: pake - PHP build tool & PEAR-dependency Management

  1. #1
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard pake - PHP build tool & PEAR-dependency Management

    Wichtig: pake wurde zu pantr umbenannt.

    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 pantr 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. ;)
    Geändert von pago (17.03.2010 um 22:20 Uhr)

  2. #2
    BIN EIN KRASSA HELD!!!111 Avatar von robo47
    Registriert seit
    02.06.2005
    Ort
    weiher im tiefsten Odenwald
    Beiträge
    1.391

    Standard

    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 ?

  3. #3
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard

    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.

  4. #4
    Erfahrener Benutzer
    Registriert seit
    16.08.2008
    Ort
    Mecklenburg-Vorpommern
    Beiträge
    449

    Standard

    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?

  5. #5
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard

    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.

  6. #6
    Erfahrener Benutzer Avatar von MrNiceGuy
    Registriert seit
    14.08.2005
    Ort
    Nienburg / Weser
    Beiträge
    876

    Standard

    Ü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.

  7. #7
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard

    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):
    Code:
    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).
    Geändert von pago (15.02.2010 um 21:10 Uhr)

  8. #8
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard

    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):
    Code:
    pear install pgs/pake-beta
    Upgrade:
    Code:
    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.

  9. #9
    Patrick Freitag
    Registriert seit
    17.08.2005
    Beiträge
    151

    Standard

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

  10. #10
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard

    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.

  11. #11
    BIN EIN KRASSA HELD!!!111 Avatar von robo47
    Registriert seit
    02.06.2005
    Ort
    weiher im tiefsten Odenwald
    Beiträge
    1.391

    Standard

    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.

  12. #12
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard

    Ich hab das Projekt nun umbenannt, um Verwechslungen mit "dem anderen" pake zu vermeiden.

    Neuer Name lautet "pantr". Neben dem neuen Namen enthält das neue Release (0.8.0) auch noch eine neue, vereinfachte Task-Definition-API. Wenn man in seiner pakefile (die nun pantrfile heißt...) den Namespace "pantr\file" verwendet, erhält man Zugriff auf die "task"-Funktion. Leider ist PHP mal wieder dumm und kann keine Funktionen aus einem Namespace importieren, deswegen ist das im Augenblick wohl die beste Möglichkeit...
    Der Task lässt sich über einen PHP-Doc-Kommentar ("/**") konfigurieren. Mehr dazu auf github.

    Das Tutorial hier im Forum habe ich bereits aktualisiert.

  13. #13
    Neuer Benutzer
    Registriert seit
    01.09.2009
    Beiträge
    17

    Standard

    Das Importieren von einzelnen Funktionen/Klassen aus einem Namespace fehlt mir leider auch, daher zögere ich noch ein wenig mit den Dingern.

    Oder hab ich da was verpasst, gibts ne Möglichkeit?

  14. #14
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard

    Bei Klassen ist das noch zu ertragen, man kann ja einfach ein "use Foo\Bar;" einbauen und hat dann die Klasse "Bar" zur Verfügung. Nur Funktionen lassen sich so nicht explizit einbauen, d.h. das beste, was man kriegen könnte wäre einen Namespace zu importieren ("use Foo\Util as f;") und dann auf die Funktionen mit f\test() zuzugreifen. Nur das ist nun auch nicht wirklich der Weisheit letzter Schluss...

    Bei pantr umgehe ich das ganze nun, indem die pantrfile (optional) im Namespace pantr\file liegt. Dadurch kann sie auf alle Funktionen in diesem Namespace zugreifen. Das ist aber auch eher ein Hack, der Aufgrund der speziellen Bedeutung der pantrfile möglich ist, als das es eine vernünftige Lösung wäre.

    Bevor ich's wieder vergesse:
    @robo: Hast du ein gutes Tutorial zu Hudson zur Hand? Ich hab mich neulich mit nem Bekannten drüber unterhalten. Er meinte, dass es ausgesprochen schwierig wäre, das vernünftig zum laufen zu bekommen. Da ich selbst noch nie praktisch mit einem CI-Server gearbeitet habe, kann ich im Augenblick schlecht abschätzen, was daran besonders gut ist und ob es sich lohnt, dort eine (in welcher Form auch immer) Integration mit pantr zu schaffen.

  15. #15
    BIN EIN KRASSA HELD!!!111 Avatar von robo47
    Registriert seit
    02.06.2005
    Ort
    weiher im tiefsten Odenwald
    Beiträge
    1.391

    Standard

    Was ist vernünftig ? :)

    Unter nem debian-basierten system muss man nur das repository von hudson hinzufügen und ein paket installieren. Dank dem recht aktiven Entwicklungsprozess und kurzen release-zyklen von hudson kommen auch alle paar Tage [gefühlt] updates rein.

    Für andere Distris [ RedHat/Fedora/CentOS/openSUSE/OpenSolaris/Nevada/FreeBSD] gibt es auch repros, da kann ich allerdings nicht zu sagen.

    Und der rest, plugins installieren und so geht alles sehr sehr komfortabel über die web-gui.

    Was die integration von php-tools und so angeht, nutze ich aktuell ant und hab mir das hier:
    Continuous Integration for PHP with Hudson at Blog :: render();
    abgeschaut.

    Spezielle Integration, ist nicht unbedingt nötig denke ich, man kann auch einfach ne binary mit parametern aufrufen.
    bei ant/phing wählt man das halt aus, sagt bei abweichung welche "build.xml" verwendet werden soll und gibt dann in nem feld die tasks ein die aufgerufen werden sollen.

  16. #16
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard

    "vernünftig" hieß bei ihm glaub ich "überhaupt". Weiß aber auch nicht, was für'n OS er benutzt, glaube fast, dass er das auf nem Windows-Rechner gemacht hat. Werd mir deinen Link mal zu Gemüte führen. Danke für die Infos! :)

    Zu pantr:
    Ich hab die PEAR-API mal General-Überholt und werde wohl die 1.0 ohne Abhängigkeit zu Pearanha anfertigen. Mit der neuen API kann man lokale PEAR Repositories erzeugen, dort Pakete hinzufügen/entfernen/aktualisieren und ist dabei deutlich sauberer.

    Meine nächste Aufgabe ist die Einführung einer "System"-API, die die ganzen Dateisystemsoperationen abstrahiert, damit ich endlich Tests/Specs für die chdir/rm/etc.-Funktionen schreiben kann. Außerdem kann man dann so ganz gut den "--dry"-Run implementieren, denke ich...

    Vielleicht mal nen Hinweis für alle, die pantr an sich nicht interessiert: Ich hab für pantr ein auf PHPUnit-basierendes Spezifikations-Framework (könnte BDD sein, da leg ich mich aber nicht drauf fest... ;) ) geschrieben. d.h. statt Tests im Sinne von Unit-Tests (mache ich das, passiert das) schreibt man mit "PSpec" (vorläufiger Name) eine Spezifikation: Die Komponente sollte dieses und jenes machen, wenn das und das passiert.
    Ist nur ne andere Syntax und ein anderes Vokabular, aber ich find's gut.

    Beispiele:
    test/spec/TaskSpec.php at develop from pago's pantr - GitHub
    test/integration/ext/PEAR/RepositorySpec.php at develop from pago's pantr - GitHub

    Wie man's aufruft steht in der pantrfile.php von pantr. Das erzeugt _genau die selbe_ Ausgabe wie PHPUnit im Normalfall erzeugen würde. Der einzige Unterschied (neben der Definition/Syntax) liegt im Fehlerfall. Dort bekommt man dann so Sachen wie "Pear Repository: it should add a channel" als "wo" angezeigt.

    Hintergrund dafür ist, dass ich meine Tests immer in der Form von "it_should_..." schreibe und irgendwann wurd's mir halt zu blöd gigantische Methoden-Namen in den Unit-Klassen zu schreiben (Beispiel: "it_should_throw_an_exception_when_colon_is_used_i n_property_name" - da fehlt sogar noch "_when_trying_to_assign_a_property"...).
    Davon abgesehen hab ich festgestellt, dass es mir leichter fällt, Tests zu schreiben, wenn ich über eine Spezifikation nachdenke, statt klassische Unit-Tests zu basteln.

    Die API ist ScalaTest nachempfunden (dem Spec-Teil davon). Man könnte also auch so Sachen wie verschachtelte describe-Aufrufe realisieren (describe("Stack") { describe("(when empty)") }).

    setUp/tearDown ist implementiert (beforeEach, afterEach, afterAll - beforeAll is nicht nötig, weil man das direkt in describe einbauen kann), fixtures können über's "SelfObject" realisiert werden.
    API an sich findet sich in /src/Pagosoft/PSpec und dort in vocab.php und den beiden Matcher-Klassen.

    Durch die PHP5.3-Syntax kann man da vorallem mit Exceptions und Konsolenausgabe viel angenehmer arbeiten, als bei "direktem" PHPUnit-Einsatz. Find ich jedenfalls.

    Offensichtlich fehlt noch ne Integration der Mock-API.

    Okay. Das war jetzt ausführlicher behandelt als gedacht, aber mich würden da Meinungen interessieren. :)

  17. #17
    Projektleiter
    Registriert seit
    30.11.2005
    Ort
    Bottrop
    Beiträge
    1.472

    Standard

    Grad Version 0.8.1 rausgehauen. Diese Version beinhaltet eine komplett umgeschriebene API für die Datei-Operationen und neue Task-Definitionen via PHPDoc-Kommentare.
    Dadurch sind die pantrfiles etwas besser lesbar und angenehmer zu schreiben. Wirkt insgesamt etwas leichter als bei der bisherigen API.

    Außerdem gibt es nun File-Tasks - die haben allerdings leider noch nicht die neue PHPDoc-API...

    Mal zum Appetit-Anregen ein Beispiel aus pantr's pantrfile:
    PHP-Code:
    <?php
    namespace pantr::file// :: sollen backslashes sein!
    /**
     * Create build directory
     *
     * @dependsOn clean
     */
    task('build:init', function() {
        
    $lib find()
            
    // we don't want to distribute vfsStream
            
    ->prune('vfsStream')->discard('vfsStream')
            ->
    prune('pear')->discard('pear'// or pear
            
    ->prune('data')->discard('data')
            
    // or the IOC-documentation and tests
            
    ->prune('doc')->discard('doc')
            ->
    prune('test')->discard('test')
            
    // and no hidden files!
            
    ->prune('.*')->discard('.*')
            ->
    not_name('.*')
            ->
    ignore_version_control()
            ->
    in('lib');

        
    // copy source files
        
    mkdirs('build/pantr');
        
    mirror($lib'build/pantr'pantr::SILENT);
        
    mirror(find()->in('src'), 'build/pantr'pantr::SILENT);
        
        
    // and executables
        
    mkdirs('build/bin');
        
    copy('bin/pantr''build/bin/pantr');
        
    copy('bin/pantr.bat''build/bin/pantr.bat');
    });
    Außerdem hab ich in pantr's pantrfile nun von manueller "--version=..." Angabe für Releases auf git tags umgestellt. Das ist vielleicht ein ganz nettes Beispiel, was so mit ant/phing vermutlich nicht ganz so einfach ist.

    Die nächste Version wird sich primär mit dem Deployment beschäftigen und eine Alternative zu Capistrano sein. Sobald das implementiert ist, werde ich erstmal meinerseits ein "Feature Freeze" verhängen, um mich um Refactorings, Tests und Dokumentation zu kümmern. Anschließend wird die Version 1.0 veröffentlicht. Soweit der Plan...

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. Antworten: 1
    Letzter Beitrag: 20.03.2006, 23:18

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Impressum · Tutorials · Nutzungsbedingungen · thematisch sortierte Linklisten · Spendenaufruf · Team · Partnerprojekte

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48