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 legt Bundles in lowercase benannten Ordnern ab:
Namespaces möchte man aber in CamelCase (hier: “Acme”) haben:
1
namespaceAcme\LocaleBundle;
Was man jetzt wissen muss: Trägt man das Bundle in einen PSR-0-Autoloader ein, dann geht das nicht:
1
2
3
"autoload":{
"psr-0":{"Acme\\":"deploy/vendor/server"}
},
, 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
1
2
3
"autoload":{
"psr-0":{"Symfony\\":"src/"},
},
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.
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
1
composer show acme/my-package--verbose
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:
1
2
3
4
{
"name":"acme/my-package",
"description":"Lorem ipsum"
}
lokale composer.json:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"name":"acme/hello-composer",
"description":"Dummy project",
"license":"proprietary",
"repositories":[
{
"type":"vcs",
"url":"https://svn.domain.tld/path/to/project/",
"package-path":"src/php/Acme/MyPackage/"
}
],
"require":{
"acme/my-package":"dev-trunk"
}
}
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.
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) 🙁