Composer
Zarządzanie zależnościami w PHP

Michał Pipa
21 czerwca 2012

O mnie

• Jestem programistą PHP
• Pracuję w firmie XSolve
• Od 5 lat używam frameworka Symfony
• https://github.com/michal-pipa
• https://connect.sensiolabs.com/profile/michal.pipa
• Silesian PHP User Group

Ankieta

• Kto programuje w PHP?
• Kto używa frameworków PHP?
• Kto słyszał o PSR-0?
• Kto używa systemu kontroli wersji?
• Kto używa Gita?

Zarządzanie zależnościami

• Większość projektów używa zewnętrznych bibliotek. Te biblioteki z kolei często wprowadzają kolejne zależności.
• Na przykład Symfony Standard Edition ma 11 zależności, które wprowadzają kolejne zależności.
• Czy wspominałem już Zend Framework (RFC: Integrate Zend\Filter into Form)?
• Problem robi się coraz większy, gdy musimy utrzymywać wiele różnych projektów.

PEAR

• PEAR instaluje pakiety globalnie
• Tworzenie własnych pakietów i własnego kanału jest skomplikowane (Pirum rozwiązuje problem tworzenia kanału, Pearfarm ułatwia tworzenie pakietów)
• Definiowanie zależności dla projektu nie jest elastyczne
• Instalacja samego narzędzia sprawia jeszcze czasem problemy
• Ogólnie jest zbyt skomplikowany (My quest to test ZendFramework...): PEAR oznacza bibliotekę, system instalacji pakietów, styl kodowania, PECL, społeczność
• Pyrus (PEAR2) nie zyskał popularności

Jak działa Composer?

• Nasz projekt używa wielu bibliotek
• Niektóre z nich używają kolejnych bibliotek
• Deklarujemy czego używamy
• Composer odnajduje jakich wersji bibliotek potrzebujemy i je instaluje

Composer

• Zarządza zależnościami, nie pakietami
• Instaluje pakiety tylko lokalnie
• Łatwy w użyciu
• Elastyczny
• Wprowadza dobre praktyki: PSR, SPDX, semver
• W tej chwili jest w wersji alpha, stabilne wydanie jest planowane na koniec lata

Composer

Inspiracja

• npm
• Bundler

Autorzy

• Nils Adermann
• Jordi Boggiano

Composer

Instalacja

$ curl -s http://getcomposer.org/installer | php
$ sudo mv composer.phar /usr/local/bin/composer

Aktualizacja

$ composer.phar self-update

Definiowanie zależności dla projektu

composer.json

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

$ composer.phar install

Installing dependencies
  - Installing monolog/monolog (1.0.2)
    Downloading: 100%

Writing lock file
Generating autoload files

Instalowanie zależności w projekcie

$ git clone git://github.com/symfony/symfony-standard.git
$ cd symfony-standard
$ composer.phar install

Installing dependencies from lock file
  - Installing doctrine/common (2.2.2)
    Downloading: 100%
[...]
symfony/symfony suggests installing doctrine/data-fixtures (1.0.*)
[...]
Generating autoload files
Clearing the cache for the dev environment with debug true
Installing assets using the hard copy option
Installing assets for Acme\DemoBundle into web/bundles/acmedemo
[...]

Co zostało utworzone?

• Katalog vendor/
• Plik composer.lock
• Konfiguracja loadera (vendor/autoload.php)

composer.lock

• Ten plik powinien być wersjonowany w VCS (razem z composer.json)
• Wersjonowanie obu tych plików zapewnia, że każdy kto będzie instalował biblioteki dla projektu, zainstaluje tę samą ich wersję
• Polecenie install w pierwszej kolejności sprawdza wersję biblioteki w composer.lock, jeżeli on istnieje
• Jeżeli composer.lock nie istnieje, to wtedy sprawdzany jest composer.json i tworzony composer.lock
• Polecenie update aktualizuje biblioteki do najnowszej wersji pasującej do composer.json i zapisuje te wersje w composer.lock

composer.lock

{
    "hash": "e4e3109acc8a04877ee974efb7478127",
    "packages": [
        {
            "package": "monolog/monolog",
            "version": "1.0.2"
        }
    ],
    "packages-dev": null,
    "aliases": [

    ],
    "minimum-stability": "dev",
    "stability-flags": [

    ]
}

Autoloader

require 'vendor/autoload.php';

Autoloader

Przykład użycia Monologa:

$log = new Monolog\Logger('name');
$log->pushHandler(new Monolog\Handler\StreamHandler('app.log',
    Monolog\Logger::WARNING));

$log->addWarning('Foo');

PSR-0

Jest to mapowanie nazwy klasy (razem z przestrzenią nazw) na ścieżkę do pliku z definicją tej klasy, aby ją następnie załadować.

\Doctrine\Common\IsolatedClassLoader
=>/path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request
=> /path/to/project/lib/vendor/Symfony/Core/Request.php
\Zend\Acl => /path/to/project/lib/vendor/Zend/Acl.php
\Zend\Mail\Message
=> /path/to/project/lib/vendor/Zend/Mail/Message.php
\namespace\package\Class_Name
=> /path/to/project/lib/vendor/namespace/package/Class/Name.php
\namespace\package_name\Class_Name
=> /path/to/project/lib/vendor/namespace/package_name/Class/Name.php

Implementacja: ClassLoader (komponent Symfony)

Packagist

• Główne repozytorium dla Composera
• ... czyli źródło pakietów
• Każdy może utworzyć tam swój projekt
• Aby korzystać z Composera pakiet niekoniecznie musi być utworzony w Packagist, ale znacznie to ułatwia korzystanie z niego

Packagist

Packagist

Typy repozytoriów

• Composer
• VCS
• PEAR
• Package

Satis

• Minimalistyczny odpowiednik Packagista
• Instalacja:

  $ composer.phar create-project composer/satis

• Użyteczny dla tworzenia prywatnych repozytoriów (zamknięty kod, firmowe repozytoria)

Pytania

Dziękuję za uwagę