Composer: Von git importieren

Am Beispiel von serbanghita/Mobile-Detect:

Im Code dann:

Learnings hier:

  • Repo-Type ist “vcs” (“git” ist veraltet)
  • Als Repository-URL genügt die oben genannte – Groß-/Kleinschreibung ist egal, .git nicht nötig
  • Der “require”-Name ergibt sich nicht von selbst – insbesondere ist es nicht das “serbanghita/Mobile-Detect” aus der Repo-URL! Um an den korrekten Namen zu kommen, guckt man entweder in die composer.json auf Git (sofern vorhanden), oder man ruft composer update -v auf (“-v” für “verbose”)
  • Ist kein Namespace definiert, darf der Slash vor “Mobile_Detect” trotzdem nicht fehlen

Composer vs. CamelCase

Composer legt Bundles in lowercase benannten Ordnern ab:

Namespaces möchte man aber in CamelCase (hier: “Acme”) haben:

Was man jetzt wissen muss: Trägt man das Bundle in einen PSR-0-Autoloader ein, dann geht das nicht:

, da PSR-0 die Datei unter einem Dateipfad sucht, der dem Namespace entspricht (deploy/vendor/server/Acme/LocaleBundle), “Acme” aber zu “acme” wird. Unter OS X kein Problem, wenn das Dateisystem caseinsensitive ist (scheint der default zu sein? Kann mich da irren), auf einem Server aber schwierig 🙂 Lösung:

1. Lowercase namespaces

Will man nicht.

2. Unterverzeichnisse nutzen

mit

in der composer.json. Kann man machen, bläht aber die Verzeichnis- (und damit die Projekt-) Struktur unnötig auf.

3. Einen eigenen Autoloader schreiben

🙂

4. PSR-4

Kurz vor Redaktionsschluss noch reingekommen: PSR-4 mit

Vorteil von PSR-4, wenn ich’s richtig verstanden habe: Die Dateien können irgendwo liegen; der Namespace wird unabhängig vom Verzeichnisbaum nur durch die Angaben im PHP-Code vorgegeben. Empfehlenswert ist aus Übersichtsgründen eine Struktur, die sich trotzdem am Namespace orientiert, aber man muss zumindest auf den Case keine Rücksicht mehr nehmen.

Composer: Erste Learnings

Ich versuche gerade, ein Composer-Package zu definieren und aus dem SVN zu installieren, bekomme aber immer die Meldung

Your requirements could not be resolved to an installable set of packages

Es wird nicht ganz klar, ob das an der packages.json im SVN liegt, an der lokalen composer.json, oder irgendwo dazwischen (zB an der Verbindung zum SVN). Leider liefert composer install auch im verbose Modus keine hilfreiche Informationen, aber

hilft. Es zeigt Informationen (zB die description) aus der packages.json (also scheint die Verbindung zum SVN zu klappen), als Version aber nur “dev-trunk”. Offenbar zählt die in der externen composer.json angegebene Version nicht, sondern allein die Tatsache, dass das Package im trunk liegt. Folgendes funktioniert schließlich:

externe composer.json:

lokale composer.json:

Wichtig dabei: “url” enthält nicht “trunk”, und alles hinter “trunk” wandert aus der URL nach “package-path”. So kann man mehrere Packages in einem SVN-Projekt ablegen.

Update “Versionierung”

Eine packages.json wird im externen Package ebensowenig benötigt, wie eine Versionsnummer in der externen composer.json! Die Versionsinformationen ergeben sich implizit aus Tag-/Branchnamen (oder halt “dev-trunk”), was ja auch Sinn macht, denn natürlich enthält das Repository alle Versionen.

Eine ganz bestimmte Revision kann man wohl mit

angeben (Quelle)

Update “SVN”

Mit dem oben beschriebenen Vorgehen muss man für jedes “require” Package ein eigenes Repository definieren. Das ist übrigens unabhängig davon, ob alle Packages in einem SVN-Projekt liegen, oder jedes Package sein eigenes Projekt hat – so lange man nicht jedem Package sein eigenes SVN-Repository geben möchte, kommt man da nicht drumrum. IMHO eine Designschwäche; Composer ist halt sehr auf git fixiert.

Anyway: Eine Möglichkeit, die “repositories” in der lokalen composer.json zu begrenzen, wäre der Einsatz von Satis:

[Satis] can be used to host the metadata of your company’s private packages, or your own.
[…]
You don’t need to copy all your repositories in every project anymore. Only that one unique repository that will update itself.

*Notwendig* ist das nicht, aber es macht die Sache übersichtlicher.

Update “SVN”/2.

Ohne Satis sind “verschachtelte” Abhängigkeiten nicht möglich (siehe), die unschöne “Lösung”: Alle Abhängigkeiten im Root-Projekt definieren (Quelle) 🙁

PS: Composer – und folglich auch Satis – laufen auf uberspace 🙂