Skorzystaj z Composera. Że co ? Że jak ?

Mar 30, 2012 − Jeśli interesujesz się Symfony 2, prawdopodobnie już słyszałeś tę magiczną nazwę: Composer. Jest pierwszy z serii wpisów w których postaram się wytłumaczyć co to jest Composer i jak z niego korzystać.

Więc czym tak naprawdę jest Composer ?

Mówiąc krótko, jest to narzędzie do zarządzania zależnościami napisane w PHP. Ale zapewne zaraz spytacie: co to znaczy ? Composer pozwala na zdefiniowanie bibliotek których wymaga Twój projekt i w łatwy sposób pozwala Ci na ich zainstalowanie w nim.

Wszystko to jest wykonywane tylko na poziomie projektu w którym Composer został uruchomiony. Jak zapewne Wam wiadomo, te idee nie są zupełnie nowe, czy rewolucyjne, ale są innowacją w świecie PHP. Prawdziwą inspiracją były tutaj takie narzędzia jak npm dla NodeJS czy też bundler dla Rubiego.

Dlaczego Composer, a nie np. PEAR ?

PEAR został zaprojektowany jako manager bibliotek na poziomie systemu, i jako taki ma wielu zwolenników, ale w wielu przypadkach staje się on problemem jeśli chodzi o zależności między bibliotekami. Wyobraźcie sobie że macie projekt który został stworzony przy wykorzystaniu Doctrine 2.1.5 (pełnej wersji: ORM, DBAL oraz Common). Zaczynacie projekt przy wykorzystaniu wersji aktualnej tj. 2.2.0, aktualizacja poprzez PEAR nie wchodzi w grę bo nasz stary projekt przestanie działać.

Tutaj pojawia się ratunek ze strony narzędzia jakim jest Composer.

Otwieramy konsolę i wywołujemy:

$ curl -s http://getcomposer.org/installer | php

Skrypt pobierze instalator, sprawdzi czy aktualna konfiguracja pozwala na bezproblemowe uruchomienie Composera i spróbuje go dla Was zainstalować. Zdefiniujmy teraz nasze wymagania dla starego projektu. Aby to zrobić powinniśmy udać się do głównego katalogu i utworzyć tam plik: composer.json oraz wypełnić w ten sposób:

{
    "require": {
        "doctrine/orm": "2.1.*"
    }
}

Teraz pozostało nam tylko wywołanie Composera aby zainstalował nam to co chcemy, tak więc w konsoli wpisujemy:

$ php composer.phar install

I to wszystko! Composer automatycznie sprawdzi zależności jakie zawiera wymagana biblioteka i je zainstaluje w katalogu vendors/ oraz utworzy plik composer.lock w którym znajdują się informacje o aktualnie wykorzystywanych wersjach bibliotek.

Teraz udajemy się do naszego drugiego projektu i tam również tworzymy plik o nazwie composer.json ale z nową zawartością:

{
    "require": {
        "doctrine/orm": "2.2.0"
    }
}

Ok, wiem jak zainstalować. Ale jak wykorzystać go w projekcie ?

Composer instalując biblioteki tworzy automatycznie plik autoloadera, tak więc po prostu otwórz aktualnie używany autoloader, w nim taki kawałek kodu:

$loader = include 'vendor/.composer/autoload.php';

W zmiennej $loader znajduje się instancja klasy Composer\Autloader\ClassLoader, która bazuje na lekko uproszczonym kodzie Symfony\Component\ClassLoader\UniversalClassLoader. Tak więc ten autoloader może zupełnie zastąpić Twój aktualny! Oto jak dodać kilka przykładowych regułek:

$loader->add('Internal_', 'some/where/in/project');
$loader->add('Namespaced\Code', 'another/place/in/project');

I gotowe!

Aktualizacja bibliotek

Zespół Doctrine wypuścił nową wersję 2.1.6 oraz 2.2.1, i co teraz ? Po prostu wpisujemy w linii komend następującą komendę:

$ php composer.phar update

Composer automatycznie sprawdzi najnowszą wersję w repozytorium Packagist (czym jest Packagist opiszę za chwilę), jeśli znajdzie nowszą, automatycznie ją ściągnie i zainstaluje wraz z wszystkim co ona wymaga, zupełnie jak przy wcześniejszej instalacji. Ale jest to możliwe dlatego iż jako wymaganą wersję wstawiliśmy: 2.1.*, gwiazdka oznacza że akceptujemy dowolną podwersję dla Doctrine 2.1

Więc dlaczego wywołaliśmy komendę update, a nie install spytacie ? Różnica między nimi tkwi nie tylko w nazwie, komenda install podczas wywołania czy plik composer.lock istnieje, jeśli go znajdzie sprawdzi czy zainstalowane wersje bibliotek zgadzają się z tymi które są w tym pliku. Tak więc ponowne wywołanie komendy install nie zaktualizuje biblioteki Doctrine!

Zapewne powiecie że wywołanie tej komendy w drugim projekcie nic nie zaktualizowało, i macie rację! Nie jest to jednak błąd Composera, po prostu jako wymaganą bibliotekę wstawiliśmy konkretną wersję.

Chcę być zawsze na bieżąco, nie ważne że mój kod może przestać działać!

Jeśli chcecie mieć zainstalowane zawsze najnowsze wersje kodu Doctrine (nie polecamy ;-)), wystarczy taka zawartość pliku composer.json:

{
    "require": {
        "doctrine/orm": "*"
    }
}

Czym jest więc wspomniany Packagist?

Pokrótce Packagist to repozytorium które jest ogólnie dostępne i zawiera informację o przeróżnych bibliotekach. Jest to tak jakby serce Composera, które zawiera wszystkie niezbędne dla niego informacje, oczywiście można to serce zastąpić bypassem, ale o tym jak i po co, postaramy się poruszyć innym razem. Wśród informacji które tam się znajdują są m.in: wszystkie dotychczasowe wersje, kto jest autorem, na jakiej licencji dana paczka jest udostępniona itp.

Podsumujmy

W tej części uzyskaliście informacje czym jest Composer i jak go używać. Jak wygląda podstawowa struktura pliku composer.json, jak również czym jest Packagist.

W następnych częściach postaram się przybliżyć jak stworzyć plik composer.json dla Twojej biblioteki oraz jak opublikować ją w repozytorium Packagist. Poruszymy bardziej zaawansowane wykorzystanie Composera z poziomu linii komend, jak również zaprezentuje Wam jak wykorzystać więcej funkcji które daje nam domyślnie konfiguracja pliku composer.json