[PHP][Composer] Instalacja i podstawy używania Composera

Composer to popularna aplikacja do obsługi zależności pomiędzy bibliotekami w zadanych projektach. Na czym to polega? Otóż pracując nad swoim projektem bardzo często wykorzystujemy jakieś biblioteki i komponenty osób trzecich. Przykładowo - pisząc aplikację korzystającą z ORM Doctrine do obsługi bazy nasza aplikacja jest zależna od tej właśnie biblioteki i wymaga jej do poprawnej pracy. Bibliotekę oczywiście możemy na stałe dołaczyć do naszego projektu, ale jest to rozwiązanie nieeleganckie.

Z pomocą przychodzi właśnie Composer - wystarczy, że spreparujemy odpowiedni plik z informacją dla Composera, w której opiszemy od jakich zewnętrznych bibliotek zależny jest nasz projekt i jakich wymaga do poprawnego działania. Composer następnie podczas instalacji naszej aplikacji odczyta nasz plik z opisem zależności, pobierze je i umieści w naszym projekcie. Takie zewnetrzne biblioteki zazwyczaj lądują w katalogu /vendor.

Co najlepsze - Composer pobierze także zależności dla bibliotek, od jakich zależna jest nasza aplikacja - bo trzeba zauważyć, że może się zdarzyć, że korzystamy z zewnętrznej biblioteki, która do swojego działania wymaga jeszcze innej zewnętrznej biblioteki. Composer wszystko to  automatycznie uwzgledni.

Z Composera korzysta wiele dużych projektów, np. instalując framework Symfony instalujemy go właśnie za pomocą Composera. Jego instalacja w systemie jest prosta i sprowadza się do kilku kroków. Opiszę poniżej sposób instalacji w systemach z rodziny Windows. W Windowsie możemy to zrobić na dwa sposoby - pobierając instalator, który zrobi wszystko za nas, lub manualnie - za pomocą terminala. Opiszę drugi sposób, żeby pokazać jak Composer wygląda "od środka".
Jeśli jednak chcemy to zrobić to automatycznie, to podaję link do instalatora: https://getcomposer.org/Composer-Setup.exe

Oficjalna strona Composera to: https://getcomposer.org/

Instalacja manualna

Zainstalujemy Composera manualnie. Pozwoli nam to zobaczyć czym tak naprawdę jest Composer.
Do zainstalowania wymagane jest PHP w wersji conajmniej 5.3.2 więc zakładam, że takową lub wyższą wersję już posiadamy. Pierwszym krokiem jest wejście w terminal, utworzenie folderu w którym Composera chcemy zainstalować i z poziomu tego folderu wykonanie komendy:

$ php -r "readfile('https://getcomposer.org/installer');" | php

Pobierze nam to Composera do katalogu, w którym się znajdujemy.
Po instalacji dopisujemy ścieżkę do folderu z Composerem do zmiennej PATH:

Dopisujemy tutaj na końcu po średniku ścieżkę do katalogu z Composerem, zatwierdzamy i ponownie uruchamiamy terminal (terminal odczytuje zmienną PATH tylko raz podczas uruchomienia).
Następnie w katalogu z Composerem tworzymy plik:

composer.bat

i wpisujemy do niego:

echo @php "%~dp0composer.phar" %*>composer.bat

Mając już dodaną ścieżkę i pobranego Composera sprawdźmy, czy wszystko działa poprawnie, wpisujac w terminalu:

$ composer -V

Powinna nam się wyświetlić informacja o aktualnie zainstalowanej wersji Composera:

Jak widzimy w katalogu - Composer to jeden plik o nazwie:

composer.phar

Czym jest PHAR? Otóż PHAR jest to spakowane archiwum z aplikacją napisaną w PHP. Możemy tworzyć takie archiwa sami pakując nasze aplikacje do tego typu archiwum, ale o tym w innym artykule. Taki plik jest normalnie uruchamiany i wykonywany przez interpreter PHP za pomocą komendy:

$ php achiwum_z_aplikacją.phar

Konfiguracja - composer.json

Wróćmy jednak do naszego Composera. Mamy już zainstalowaną aplikację, pora teraz na wytłumaczenie kilku spraw odnośnie używania Composera. Po pierwsze - tak jak to zostało wspomniane na wstępie - dla Composera musi zostać przygotowany specjalny plik, który określi mu listę zależności jakie należy pobrać i doinstalować. Plik taki przygotowujemy w formacie JSON i umieszczamy w katalogu z aplikacją, dla której chcemy pobrać zależne biblioteki. Nazwa takiego pliku to zawsze:

composer.json

a jego zawartość wygląda tak:

{
 
    "require": {
 
        "dostawca/nazwa_aplikacji": "wersja_aplikacji"
 
    }
 
}

Przykładowo, jeśli chcemy zawrzeć tutaj np. pakiet Smarty, który chcemy dołączyć do naszej aplikacji - podać możemy:

{
 
    "require": {
 
        "smarty/smarty": "3.1.19"
 
    }
 
}

co oznaczać będzie dokładnie to: moja aplikacja wymaga do działania biblioteki smarty od dostawcy o nazwie smarty w wersji 3.1.19.

Instalacja zależności - composer install

Sprawdźmy teraz to w praktyce. Utwórzmy katalog o nazwie smarty i wejdźmy do niego w terminalu.
W katalogu tym umieśćmy plik composer.json o treści:

{
 
    "require": {
 
        "smarty/smarty": "~3.1"
 
    }
 
}

(przed cyfrą 3 znajduje się znak tyldy jeśli jest to mało widoczne)
Następnie wykonajmy polecenie:

$ composer install

które pobierze i zainstaluje nam tutaj pakiet Smarty w najnowszej dostępnej wersji z gałęzi 3.1.x:

Możemy też przekopiować plik composer.phar do tego katalogu i wykonać go poleceniem:

$ php composer.phar install

Zobaczmy teraz w naszym folderze - jeśli wszystko poszło dobrze to Smarty zostało zainstalowane do katalogu /vendor:

Przy okazji, jak widzimy - utworzył się nam tam też plik:

autoload.php

o treści mniej więcej takiej:

<?php
 
 
 
// autoload.php @generated by Composer
 
 
 
require_once __DIR__ . '/composer' . '/autoload_real.php';
 
 
 
return ComposerAutoloaderInit9ff9d8a01182b790e18358de1f571cba::getLoader();

Autoładowanie klas - autoload.php

Composer jak widzimy automatycznie tworzy plik autoładujący dołączane biblioteki! Nie musimy więc martwić się o odpowiednie dołączanie pobieranych bibliotek, wystarczy teraz, że w naszym projekcie podamy jedynie ścieżkę do autoloadera stworzonego przez Composera:

<?php
 
require __DIR__ . '/vendor/autoload.php';
 
?>

a całą resztę - związaną z załadowaniem odpowiednich klas wykona już za nas on sam, a konrektnie plik autoload.php przez niego wygenerowany. Jest to bardzo fajna i przydatna funkcjonalność Composera. Oczywiście nic nie stoi na przeszkodzie, aby korzystać z własnego autoloadera, Composer niczego tutaj na nas nie wymusza, a jedynie oferuje funkcjonalność z której jeśli chcemy to możemy skorzystać.

Wersjonowanie

Pobierając pakiet Smarty podaliśmy w pliku composer.json następującą nazwę wymaganej wersji:

~3.1

(z tyldą na początku)

W Composerze możemy określić nazwę wymaganej wersji wg kilku odpowiednich wytycznych. Służy do tego odpowiednia składnia, która wygląda następująco:

• 1.0.0 - określa, że wymagana jest DOKŁADNIE wersja 1.0.0
• >=1.0 - określa, że wymagana jest wersja conajmniej 1.0, w przypadku istnienia wersji nowszej od 1.0 Composer pobierze najnowszą dostępną wersję
• >=1.0 < 2.1 - określa, że wymagana jest wersja conajmniej 1.0, ale mniejsza niż 2.1
• 1.0 - 3.0 - określa, że interesuje nas wersja z przedziału od 1.0 do 3.0
• 1.0.* - określa, że interesuje nas wersja z przedziału od 1.0.x do 1.1.0
• ~1.3 - określa, że interesuje nas wersja z przedziału 1.3, ale mniejsza od następnego końcowego numerka, czyli 1.4, np. 1.3.1, 1.3.5, 1.3.9,
• ^1.3 - określa, że intersuje nas wersja większa lub równa 1.3, ale mniejsza od następnego początkowego numerka, czyli 2.0, np. 1.3, 1.8, 1.9.9

Composer zawsze pobiera najnowszą aktualnie dostępną wersję z zadanego przedziału, lub konkretnie tą jedną wymaganą, jeśli zamiast przedziału podajemy dokładny numer wersji.

Blokada wersji - composer.lock

W katalogu do którego pobieraliśmy Smarty jak może już zauważyliśmy utworzył się jeszcze jeden plik - composer.lock.
Warto wiedzieć do czego on słuzy. Otóż w pliku tym Composer zapisuje informacje o aktualnie pobranych tutaj zależnościach (w naszym przypadku - Smarty) i ich dokładnych wersjach.
Wyobraźmy sobie teraz, że hostujemy nasz projekt jako repozytorium na GitHUB-ie, do którego ma dostęp cała masa innych programistów. Programista taki klonuje sobie nasze repozytorium, instaluje do niego wymagane zależności dzięki plikowi composer.js, który mówi mu jakie zależności pobrać należy i nagle okazuje się, że otrzymuje do pracy lekko odmienną wersję. Dlaczego?

Ponieważ np. w pliku composer.json określiliśmy, iż nasza aplikacja wymaga do pracy danej biblioteki w wersji conajmniej 1.1 i taka też najnowsza wersja była dostępna w momencie commitowania repozytorium. Godzinę później natomiast dostawca naszej zależności wypuszcza wersję 1.2, która od tej pory staje się najnowszą dostępną wersją. Programista jaki teraz pobierze nasze repozytorium i instalując zależności przez Composera otrzyma już nie wersję 1.1, a wersję 1.2. I do prewencji przed takim czymś służy właśnie plik composer.lock.

Określa on, jaka jest aktualna wersja zależności na której obecnie pracujemy. Jeśli teraz w pliku composer.lock mamy zapisaną informację, iż w momencie wysyłania repozytorium pracujemy z wersją 1.1 zależnej biblioteki, to programista klonujący nasze repozytorium otrzyma od Composera właśnie taką wersję, a my będziemy mieli pewność, że osoba, która teraz pracuje z naszym repozytorium pracuje na DOKŁADNIE takiej samej wersji plików jak my.

Dlatego pamiętajmy o tym, aby podczas commita zawsze wysyłać do repozytorium również plik composer.lock.

Aktualizacja zależności - composer update

Aktualizacji do nowszej wersji danej zależności (o ile taka wyszła) dokonujemy za pomocą:

$ composer update

W przypadku nowszych wersji, niż ta którą posiadamy wyświetli się nam po prostu komunikat Nothing to update:

Jeśli natomiast pojawila się nowsza wersja (np. Smarty w naszym przypadku) to Composer ją pobierze i zaktualizuje nam bibliotekę do nowszej wersji. Jeśli natomiast korzystamy z kilku zależności, a chcemy zaktualizować tylko jedną, lub kilka określonych podajemy je po spacji za komendą update, np.:

$ composer update smarty/smarty inna/inna jeszcze_inna/jeszcze_inna

Jak widzimy, Composer to bardzo fajne i pomocne narzędzie. Za takim stwierdzeniem świadczyć powinien choćby fakt, iż wszystkie większe projekty korzystają z jego dobrodziejstw. Zapoznanie się z nim jest więc czasem wręcz konieczne. Mam nadzieję, że dzięki temu wpisowi umiecie już w podstawowy korzystać z Composera. W następnym artykule opiszę w jaki sposób utworzyć i udostępnić swoją własną paczkę, tak aby można ją było pobrać poprzez wpis w composer.json.