Установка php с использованием composer. Пакетный менеджер composer. Подключаем на собственный Compsoer-пакет

Composer произвел революцию в управлении пакетами в PHP и помог разработчикам по всему миру создавать независимый от фреймворков и разделяемый код. Но все же мало кто выходит за рамки основ его функционала, так что данная статья постарается осветить некоторые полезные приемы его использования.

Глобальная установка (Global)

Несмотря на то, что данная опция доступно описана в документации, Composer может (а в большинстве случаев должен) быть установлен глобально. Глобальная установка означает, что вместо:

Php composer.phar somecommand
Вы можете в любом проекте просто ввести:

Composer somecommand
Это позволяет очень просто создавать новые проекты (например, с помощью команды create-project ) в любом месте вашей файловой системы.

Для установки Composer глобально, следуйте этим инструкциям .

Правильная установка зависимостей

При чтении вводных инструкций или README файлов многие напишут вам что-то вроде:

Just add the following to your composer.json file :
{ "require": { "myproject": "someversion" } }

Но данный подход имеет несколько недостатков. Во-первых, простой копипаст может привести к возникновению ошибок. Во-вторых, для новичка может быть не очевидно, где разместить данный код, если у него и так уже имеется обширный файл composer.json , и это также привести к ошибке. Наконец, некоторые люди будут иметь дело с Composer впервые, а возможно и впервые столкнутся с командной строкой. Поэтому хорошей практикой будет освещение всевозможных случаев, в которых новички могут чувствовать себя неуверенно (есть ли у них графический редактор или они будут использовать командную строку? Если второе, установлен ли в ней текстовый редактор, и если да, то какой? Объясняете ли вы саму процедуру редактирования файла? А что если файла composer.json ещё не существует в проекте? Описываете ли также принцип создания нового файла?).

Наилучший способ добавить новую зависимость в файл composer.json - это воспользоваться командой require :

Composer require somepackage/somepackage:someversion
Это добавит все необходимое в файл зависимостей, минуя ручное вмешательство.

Если вам нужно добавить пакеты в раздел require-dev , добавьте в команду опцию --dev :

Composer require phpunit/phpunit --dev
Также, команда require поддерживает добавление нескольких пакетов одновременно, для этого просто разделите их пробелом.

Файлы блокировок

Файл composer.lock сохраняет текущий список установленных зависимостей и их версии. Таким образом, на момент, когда версии зависимостей уже будут обновлены, другие люди, которые будут клонировать ваш проект, получат те же самые версии. Это позволяет убедиться в том, что каждый, кто получает ваш проект, имеет “пакетное окружение”, идентичное тому, которое вы использовали при разработке, и помогает избежать ошибок, которые могли бы возникнуть из-за обновления версий.

Также, файл composer.lock содержит хэш файла composer.json , так что, если вы даже просто обновляете данные об авторе проекта, вы получите предупреждение о том, что файл блокировки не соответствует .json файлу. В таком случае, поможет команда composer update --lock , которая обновит только сам файл блокировки, не касаясь ничего другого.

Версионирование

При указании допустимых версий пакетов можно использовать точное соответствие (1.2.3 ), диапазоны с операторами сравнения (<1.2.3 ), комбинации этих операторов (>1.2.3 <1.3 ), “последняя доступная” (1.2.* ), символ тильды (~1.2.3 ) и знак вставки (^1.2.3 ).

Последние два указания достойны отдельного объяснения:

• указание тильды (~1.2.3 ) будет включать в себя все версии до 1.3 (не включительно), так как в семантическом версионировании это является моментом внедрения новых функциональных возможностей. В данном случае будет получена последняя из стабильных минорных версий. Как гласит документация, при данном указании изменяться может только последняя цифра версии.
• указание знака вставки (^1.2.3 ) буквально означает “опасаться только критических изменений” и будет включать в себя версии вплоть до 2.0 . Применительно к semver, изменение мажорной версии является моментом внесения в проект критических изменений, так что версии 1.3 , 1.4 и 1.9 подходят, в то время как 2.0 - уже нет.

Кроме случая, когда вы знаете, что вам нужна конкретная версия пакета, я рекомендую всегда использовать формат ~1.2.3 - это самый безопасный выбор.

Локальная и глобальная конфигурация

Значения параметров по-умолчанию не высечены на камне. Подробное описание возможных параметров конфигураций (config ) см. по ссылке .

Например, указав:
{ "config": { "optimize-autoloader": true } }
вы заставляете Composer оптимизировать classmap после каждой установки или обновления пакетов (или, другими словами, всякий раз, когда генерируется файл автозагрузки классов). Это немного медленнее, чем создание автозагрузчика по-умолчанию, и замедляется при росте проекта.

Ещё одним полезным параметром может быть cache-files-maxsize . В больших проектах (как eZ Publish или Symfony) кэш может заполниться довольно быстро. Увеличение размера кэша позволить Composer работать быстро дольше.

Обратите внимание, что параметры конфигурации могут быть установлены глобально, и в таком случае будут действовать на все проекты (см. config). Например, чтобы глобально установить параметр размера кэша, нужно либо отредактировать файл ~/.composer/config.json , либо выполнить:

Composer config --global cache-files-maxsize "2048MiB"

Профилирование и подробный вывод (verbose)

Если вы добавите параметр --profile к любой команде при использовании Composer в командной строке, то в выводе будет содержаться не только конечный результат, например:

Memory usage: 174.58MB (peak: 513.47MB), time: 54.7s
Но также в начало каждой строки вывода будет добавлено время выполнения команды и использованный размер памяти:

Installing assets for Sensio\Bundle\DistributionBundle into web/bundles/sensiodistribution
Я использую данную опцию для определения “медленных” пакетов и для наблюдения за улучшением или ухудшением производительности на .

Подобно предыдущему, параметр --verbose заставит Composer выводить больше информации о каждой выполняемой операции, давая вам понять, что именно происходит в данный момент. Некоторые люди даже устанавливают composer --verbose --profile псевдонимом команды composer по-умолчанию.

Пользовательские источники

Если ваш проект ещё не на Packagist, иногда вам нужно просто установить пакет с GitHub (например, если пакет ещё находится в разработке). Для этого см. наше руководство .

Когда у вас есть своя версия популярного пакета, от которого зависит ваш проект, вы можете использовать пользовательские источники в сочетании с контекстными псевдонимами (inline aliasing), чтобы подставить собственную ветку для публичного пакета, как Matthieu Napoli.

Ускорение Composer

Используя отличный метод, описанный Mark Van Eijk , вы можете ускорить выполнение Composer, вызывая его через HHVM.

Ещё один способ - с помощью параметра --prefer-dist , при установке которого Composer будет скачивать стабильные, запакованные версии проекта, вместо клонирования из системы контроля версий (что значительно медленнее). Этот параметр используется по-умолчанию, так что вам не нужно включать его на стабильных проектах. Если вам нужно загрузить проект из исходников, используйте параметр --prefer-source . Подробнее об этом можно узнать в разделе install .

Уменьшение размера проекта Composer

Если вы разработчик «Composer-friendly» проектов, данная часть вас также заинтересует. По этому посту в Reddit , вы можете с помощью файла .gitattributes игнорировать некоторые файлы и папки во время упаковки пакета для режима --prefer-dist .
/docs export-ignore /tests export-ignore /.gitattributes export-ignore /.gitignore export-ignore /.travis.yml export-ignore /phpunit.xml export-ignore
Как это работает? Когда вы загружаете проект на GitHub, он автоматически делает доступным ссылку “Download zip” , с помощью которой вы можете скачать архив вашего проекта. Более того, Packagist использует эти автоматически сгенерированные архивы для скачивания зависимостей с опцией --prefer-dist , которые он затем локально разархивирует (намного быстрее клонирования исходных файлов проекта). Если вы при этом добавите в .gitattributes тесты, документацию и прочие файлы, не имеющие отношения к логике работы проекта, указанные архивы не будут их содержать, став гораздо легче.

При этом людям, которые захотят отладить вашу библиотеку или запустить тесты, нужно будет указать параметр --prefer-source .

PhpLeague приняла этот подход и включила его в свой «скелет пакета» (Package skeleton), так что любой основанный на нем проект автоматически будет “dist friendly” .

Show

Если вы вдруг забыли, какую версию PHP или его расширения используете, или вам нужен список всех установленных проектов (с описанием каждого) с их версиями, вы можете использовать команду show с параметрами --platform (-p ) и --installed (-i ):

composer show --installed

$ composer show --installed behat/behat v3.0.15 Scenario-oriented BDD framework for PHP 5.3 behat/gherkin v4.3.0 Gherkin DSL parser for PHP 5.3 behat/mink v1.5.0 Web acceptance testing framework for PHP 5.3 behat/mink-browserkit-driver v1.1.0 Symfony2 BrowserKit driver for Mink framework behat/mink-extension v2.0.1 Mink extension for Behat behat/mink-goutte-driver v1.0.9 Goutte driver for Mink framework behat/mink-sahi-driver v1.1.0 Sahi.JS driver for Mink framework behat/mink-selenium2-driver v1.1.1 Selenium2 (WebDriver) driver for Mink framework behat/sahi-client dev-master ce7bfa7 Sahi.js client for PHP 5.3 behat/symfony2-extension v2.0.0 Symfony2 framework extension for Behat behat/transliterator v1.0.1 String transliterator components/bootstrap 3.3.2 The most popular front-end framework for developing responsive, mobile first projects on the web. components/jquery 2.1.3 jQuery JavaScript Library doctrine/annotations v1.2.4 Docblock Annotations Parser doctrine/cache v1.4.1 Caching library offering an object-oriented API for many cache backends doctrine/collections v1.3.0 Collections Abstraction library doctrine/common v2.5.0 Common Library for Doctrine projects doctrine/dbal v2.5.1 Database Abstraction Layer doctrine/doctrine-bundle v1.4.0 Symfony DoctrineBundle doctrine/doctrine-cache-bundle v1.0.1 Symfony2 Bundle for Doctrine Cache doctrine/inflector v1.0.1 Common String Manipulations with regard to casing and singular/plural rules. doctrine/instantiator 1.0.4 A small, lightweight utility to instantiate objects in PHP without invoking their constructors doctrine/lexer v1.0.1 Base library for a lexer that can be used in Top-Down, Recursive Descent Parsers. egulias/listeners-debug-command-bundle 1.9.1 Symfony 2 console command to debug listeners ezsystems/behatbundle dev-master bd95e1b Behat bundle for help testing eZ Bundles and projects ezsystems/comments-bundle dev-master 8f95bc7 Commenting system for eZ Publish ezsystems/demobundle dev-master c13fb0b Demo bundle for eZ Publish Platform ezsystems/demobundle-data v0.1.0 Data for ezsystems/demobundle ezsystems/ezpublish-kernel dev-master 3d6e48d eZ Publish API and kernel. This is the heart of eZ Publish 5. ezsystems/platform-ui-assets-bundle v0.5.0 External assets dependencies for PlatformUIBundle ezsystems/platform-ui-bundle dev-master 4d0442d eZ Platform UI Bundle ezsystems/privacy-cookie-bundle v0.1 Privacy cookie banner integration bundle into eZ Publish/eZ Platform fabpot/goutte v1.0.7 A simple PHP Web Scraper friendsofsymfony/http-cache 1.3.1 Tools to manage cache invalidation friendsofsymfony/http-cache-bundle 1.2.1 Set path based HTTP cache headers and send invalidation requests to your HTTP cache guzzle/guzzle v3.9.3 PHP HTTP client. This library is deprecated in favor of https://packagist.org/packages/guzzlehttp/guzzle hautelook/templated-uri-bundle 2.0.0 Symfony2 Bundle that provides a RFC-6570 compatible router and URL Generator. hautelook/templated-uri-router 2.0.1 Symfony2 RFC-6570 compatible router and URL Generator imagine/imagine 0.6.2 Image processing for PHP 5.3 incenteev/composer-parameter-handler v2.1.0 Composer script handling your ignored parameter file instaclick/php-webdriver 1.0.17 PHP WebDriver for Selenium 2 jdorn/sql-formatter v1.2.17 a PHP SQL highlighting library knplabs/knp-menu v1.1.2 An object oriented menu library knplabs/knp-menu-bundle v1.1.2 This bundle provides an integration of the KnpMenu library kriswallsmith/assetic v1.2.1 Asset Management for PHP kriswallsmith/buzz v0.13 Lightweight HTTP client league/flysystem 0.5.12 Many filesystems, one API. liip/imagine-bundle 1.2.6 This Bundle assists in imagine manipulation using the imagine library monolog/monolog 1.13.1 Sends your logs to files, sockets, inboxes, databases and various web services nelmio/cors-bundle 1.3.3 Adds CORS (Cross-Origin Resource Sharing) headers support in your Symfony2 application ocramius/proxy-manager 0.5.2 A library providing utilities to generate, instantiate and generally operate with Object Proxies oneup/flysystem-bundle v0.4.2 Integrates Flysystem filesystem abstraction library to your Symfony2 project. pagerfanta/pagerfanta v1.0.3 Pagination for PHP 5.3 phpdocumentor/reflection-docblock 2.0.4 phpspec/prophecy v1.4.1 Highly opinionated mocking framework for PHP 5.3+ phpunit/php-code-coverage 2.0.16 Library that provides collection, processing, and rendering functionality for PHP code coverage information. phpunit/php-file-iterator 1.4.0 FilterIterator implementation that filters files based on a list of suffixes. phpunit/php-text-template 1.2.0 Simple template engine. phpunit/php-timer 1.0.5 Utility class for timing phpunit/php-token-stream 1.4.1 Wrapper around PHP"s tokenizer extension. phpunit/phpunit 4.6.4 The PHP Unit Testing framework. phpunit/phpunit-mock-objects 2.3.1 Mock Object library for PHPUnit psr/log 1.0.0 Common interface for logging libraries qafoo/rmf 1.0.0 Very simple VC framework which makes it easy to build HTTP applications / REST webservices sebastian/comparator 1.1.1 Provides the functionality to compare PHP values for equality sebastian/diff 1.3.0 Diff implementation sebastian/environment 1.2.2 Provides functionality to handle HHVM/PHP environments sebastian/exporter 1.2.0 Provides the functionality to export PHP variables for visualization sebastian/global-state 1.0.0 Snapshotting of global state sebastian/recursion-context 1.0.0 Provides functionality to recursively process PHP variables sebastian/version 1.0.5 Library that helps with managing the version number of Git-hosted PHP projects sensio/distribution-bundle v3.0.21 Base bundle for Symfony Distributions sensio/framework-extra-bundle v3.0.7 This bundle provides a way to configure your controllers with annotations sensio/generator-bundle v2.5.3 This bundle generates code for you sensiolabs/security-checker v2.0.2 A security checker for your composer.lock swiftmailer/swiftmailer v5.4.0 Swiftmailer, free feature-rich PHP mailer symfony-cmf/routing 1.3.0 Extends the Symfony2 routing component for dynamic routes and chaining several routers symfony/assetic-bundle v2.6.1 Integrates Assetic into Symfony2 symfony/monolog-bundle v2.7.1 Symfony MonologBundle symfony/swiftmailer-bundle v2.3.8 Symfony SwiftmailerBundle symfony/symfony v2.6.6 The Symfony PHP framework tedivm/stash v0.12.3 The place to keep your cache. tedivm/stash-bundle v0.4.2 Incorporates the Stash caching library into Symfony. twig/extensions v1.2.0 Common additional features for Twig that do not directly belong in core twig/twig v1.18.1 Twig, the flexible, fast, and secure template language for PHP white-october/pagerfanta-bundle v1.0.2 Bundle to use Pagerfanta with Symfony2 whiteoctober/breadcrumbs-bundle 1.0.2 A small breadcrumbs bundle for Symfony2 zendframework/zend-code 2.2.10 provides facilities to generate arbitrary code using an object oriented interface zendframework/zend-eventmanager 2.2.10 zendframework/zend-stdlib 2.2.10 zetacomponents/base 1.9 The Base package provides the basic infrastructure that all packages rely on. Therefore every component relies on this package. zetacomponents/feed 1.4 This component handles parsing and creating RSS1, RSS2 and ATOM feeds, with support for different feed modules (dc, content, creativeCommons, geo, iTunes). zetacomponents/mail 1.8.1 The component allows you construct and/or parse Mail messages conforming to the mail standard. It has support for attachments, multipart messages and HTML mail. It also interfaces with SMTP to send mail or IMAP, P... zetacomponents/system-information 1.1 Provides access to common system variables, such as CPU type and speed, and the available amount of memory.

Репетиции (Dry Runs)

Чтобы просто посмотреть, пройдет ли установка новых зависимостей успешно, вы можете использовать параметр --dry-run для команд install и update . Composer в данном случае выведет все потенциальные проблемы без непосредственного выполнения самой команды. Никаких реальных изменений в проекте не произойдет. Этот прием отлично подходит для тестирования сложных зависимостей и настройки изменений перед реальным их внесением.

Composer update --dry-run --profile --verbose

Создание проекта

Последнее, но не менее важное, что мы должны упомянуть - это команда create-project .

Команда создания проекта принимает в качестве аргумента имя пакета, который она затем клонирует и выполняет composer install внутри него. Это отлично подходит для инициализации проектов - не нужно больше искать Url нужного пакета на GitHub, клонировать его, самому переходить в папку и выполнять команду install .

Крупные проекты, такие как Symfony и Laravel, уже используют данный подход для инициализации своих «skeleton» приложений, и многие другие также присоединяются.

Например, в Laravel это используется следующим образом:

Composer create-project laravel/laravel --prefer-dist --profile --verbose
В команду create-project можно передать еще два параметра: путь , в который нужно установить проект (если не указан, используется имя пакета), и версия (будет использована последняя, если не указать).

Заключение

Надеюсь, данный список советов и приемов использования оказался для вас полезным. Если мы что-то упустили, расскажите нам об этом, и мы обновим статью. И помните, если вы забыли какие-либо команды или опции, просто загляните в шпаргалку . Happy Composing!

У меня знакомство с Composer началось с того, что мы начали внедрять проект на фреймворке YII 2. YII 2 еще был в стадии alpha-версии и, кроме того, что он представлял собой мало документированный инструмент, так еще и тянул за собой кучу не знакомых технологий. Что нужно для того, чтобы начать работать с YII 2 я упомянул .

Вот, как проводилось это наше знакомство, где мой коллега рассказывает о том, как мы можем применить Composer в нашем проекте:

Composer — это менеджер зависимостей. Который позволяет по принципу модулей подключать к своей системе код сторонних разработчиков. Кратко, как это работает:

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

Что умеет Composer?

• Скачивать пакеты и их зависимости;
• по умолчанию, пакеты скачиваются из официального репозитория packagist.org. Любой человек может свободно добавить туда свой пакет, чтобы сделать его установку максимально лёгкой и удобной для всего мира;
• пакеты можно скачивать не только с packagist.org, но и из любого git, mercurial или svn репозитория;
• при скачивании пакетов с github.com или bitbucket.org не требуется установленной системы контроля версий (git или hg), Composer работает через API этих сайтов;
• git/hg/svn репозиторий с пакетом может находиться не только на одном из перечисленных выше сайтов, но в любом другом месте, например, в локальной сети предприятия или вообще на локальном жестком диске;
• кроме того, устанавливаемая библиотека не обязательно должна быть оформлена в виде Composer-пакета, вы можете сделать установку из любого git/hg/svn репозитория произвольной структуры;
• наконец, устанавливаемый пакет не обязательно должен быть git/hg/svn репозиторием, это может быть произвольный zip файл доступный по любому uri!
• все пакеты устанавливаются в текущую директорию (откуда была выполнена команда install), это позволяет иметь несколько различных версий библиотек при работе над разными проектами параллельно;
• команда update обновляет все установленные (или установит заново случайно удалённые) пакеты до свежих версий. А может и не обновлять версии до самых свежих, если создать специальный composer.lock файл — это позволяет зафиксировать комбинацию из стабильных версий всех используемых в проекте библиотек;
• после установки пакетов автоматически генерируется autoload.php, с помощью которого можно подключить установленные библиотеки в коде вашего проекта. При подготовке Composer-пакета рекомендуется использовать PSR-0 — стандарт расположения и именования php файлов, чтобы autoload смог их легко найти. В любом случае, автор пакета может описать правила, по которым autoload будет искать файлы тех или иных классов или неймспейсов. Если вы устанавливаете библиотеку, которая не оформлена как Composer-пакет (например, произвольный git репозиторий с github), то задача описания правил autoload ложится на ваши плечи. Так что никакой магии с генерируемым autoload.php нет — он умеет загружать всё (даже библиотеки с набором функций вне классов), главное, чтобы были описаны правила (автором библиотеки или вами).

Как мы делали раньше, когда не было Composer: скачивали нужные нам фреймворки и библиотеки, думали куда их распаковать, писали в проекте кучу require (или require_once для надёжности).

Как мы поступаем теперь, когда у нас есть Composer: он сам скачает все библиотеки и сгенерирует для нас autoload.php. Кроме того, если мы захотим показать «Super Hello World» коллегам, достаточно будет опубликовать код нашего проекта на github (или ещё где-нибудь), не включая всех требуемых библиотек в репозиторий и не готовя длинной инструкции по их установке. Нашим коллегам достаточно будет скачать (склонировать) «Super Hello World» и выполнить команду

1	php composer. phar install

php composer.phar install

Composer распространяется в виде одного файла composer.phar (phar - это php-архив) - по сути это PHP скприт, который может принимать несколько команд (install, update, …) и умеет скачивать и распаковывать библиотеки.

При настройке своего проекта и установки зависимостей для него, нужно помнить, что голова всему - это файл composer.json. Он должен быть в корне проекта, в нашем случае рядом с директориями web и view (YII 2). В этом файле необходимо указать от каких библиотек зависит наш проект. Кроме того, если эти библиотеки не являются оформленными Composer-пакетами, то нужно указать некоторую дополнительную информацию об устанавливаемой библиотеке (например, описать правила автозагрузки классов и функций для autoload.php).

composer.json, имеет формат данных JSON. На вопрос «почему именно JSON?» разработчики Composer отвечают «Потому что. Просто примите это.».

Нам нужно описать один js-объект, в котором будут находиться все инструкции. Первая и самая главная инструкция: require.
Подключаем пакеты с сайта packagist.org:

1 2 3 4 5 6 7

{ "require" : { "php" : ">=5.3.0" , "silex/silex" : "dev-master" , "twig/twig" : ">=1.8,<2.0-dev" } }

{ "require": { "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev" } }

Здесь я описал зависимость проекта от PHP версии 5.3.0 и выше, от silex (микрофреймворк) и от twig (шаблонизатор). Silex и Twig доступны в виде Composer-пакетов на сайте packagist.org, поэтому дополнительных настроек не требуют. Замечу, что Silex в свою очередь зависит ещё от нескольких пакетов - все они будут скачены и установлены автоматически.

Имя пакета состоит из двух частей разделёных косой чертой: названия поставщика (vendor name) и названия библиотеки. Названием поставщика зачастую является ник автора или имя компании. Иногда, название поставщика совпадает с именем самой библиотеки или фреймворка.

Для каждого пакета обязательно нужно указать номер версии. Это может быть бранч в репозитории, например, «dev-master» - приставка dev сигнализирует, что это имя бранча, а сам бранч соответсвенно называется «master». Кстати, если вы скачиваете код из удалённого репозитория, то Composer сканирует теги и имена веток в этом репозитории на предмет чего-то похожего на номера версий, например тег «v1.2.3» будет использован как указатель на версию 1.2.3.

Подключаем наш собственный Composer-пакет

1 2 3 4 5 6 7 8 9 10 11 12 13 14

{ "require" : { "php" : ">=5.3.0" , "silex/silex" : "dev-master" , "twig/twig" : ">=1.8,<2.0-dev" , "mycompany/superlogger" : "dev-master" } , "repositories" : [ { "type" : "git" , "url" : } ] }

{ "require": { "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" } ] }

Чтобы Composer знал где искать пакет «mycompany/superlogger», мы добавили массив repositories со ссылкой на соотвествующий github репозиторий. Обратим внимание, что записи в массиве repositories напрямую никак не связаны с блоком require - между пакетами и репозиториями не указано соответствие. На сколько я понял, Composer ищет все требуемые пакеты во всех указанных репозиториях (в т.ч. на сайте packagist.org) и скачивает найденные совпадения по каким-то внутренним приоритетам. Более глубоко я в этом моменте ещё не разбирался, поправьте меня, если кто-то знает детали.

Подключаем произвольный git репозиторий

Теперь подключим нашу легаси-библиотеку superlib, которая лежит на github, но не является оформленным Composer-пакетом, т.к. она очень старая.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

{ "require" : { "php" : ">=5.3.0" , "silex/silex" : "dev-master" , "twig/twig" : ">=1.8,<2.0-dev" , "mycompany/superlogger" : "dev-master" , "pqr/superlib" : "1.2.3" } , "repositories" : [ { "type" : "git" , "url" : "http://github.com/pqr/superlogger" } , { "type" : "package" , "package" : { "name" : "pqr/superlib" , "version" : "1.2.3" , "source" : { "type" : "git" , "url" : "http://github.com/pqr/superlib" , "reference" : "master" } , "autoload" : { "classmap" : [ "timer.php" ] , "files" : [ "lib_functions.php" ] } } } ] }

{ "require":{ "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master", "pqr/superlib":"1.2.3" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" }, { "type":"package", "package":{ "name":"pqr/superlib", "version":"1.2.3", "source":{ "type":"git", "url":"http://github.com/pqr/superlib", "reference":"master" }, "autoload":{ "classmap":["timer.php"], "files":["lib_functions.php"] } } } ] }

В массив repositories добавился объект, который целиком описывает пакет pqr/superlib. По сути, это то описание, которое должен был бы сделать автор библиотеки и положить его внутри своего репозитория. Но по условиям задачи, superlib не является оформленным Composer-пакетом, поэтому нам пришлось создать его описание в рамках Super Hello World проекта. Аналогичным образом можно подключить любую другую библиотеку, в т.ч. простой zip файл.

Подключаем простой zip файл

Например, вот как могло бы выглядеть описание зависимости от шаблонизатора Smarty, распространяемого в виде zip файла с исходниками в svn:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

{ "repositories" : [ { "type" : "package" , "package" : { "name" : "smarty/smarty" , "version" : "3.1.7" , "dist" : { "url" : "http://www.smarty.net/files/Smarty-3.1.7.zip" , "type" : "zip" } , "source" : { "url" : "http://smarty-php.googlecode.com/svn/" , "type" : "svn" , "reference" : "tags/Smarty_3_1_7/distribution/" } } } ] , "require" : { "smarty/smarty" : "3.1.*" } }

{ "repositories":[ { "type":"package", "package":{ "name":"smarty/smarty", "version":"3.1.7", "dist":{ "url":"http://www.smarty.net/files/Smarty-3.1.7.zip", "type":"zip" }, "source":{ "url":"http://smarty-php.googlecode.com/svn/", "type":"svn", "reference":"tags/Smarty_3_1_7/distribution/" } } } ], "require":{ "smarty/smarty":"3.1.*" } }

) - это относительно новый и уже достаточно популярный менеджер зависимостей для PHP. Вы можете описать от каких библиотек зависит ваш проект и Composer установит нужные библиотеки за вас! Причём Composer - это не менеджер пакетов в классическом понимании. Да, он оперирует с сущностями, которые мы будем называть «пакетами» или библиотеками, но устанавливаются они внутрь каждого проекта отдельно, а не глобально (это одно из основных отличий от старого-доброго PEAR).

Кратко, как это работает:

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

При создании Composer авторы черпали идеи и вдохновение из аналогичных проектов: npm для Node.js и Bundler для Ruby.

Изначально он был спроектирован и разработан двумя людьми Nils Adermann и Jordi Boggiano , сейчас в проекте участвует более двадцати контрибьюторов, Проект написан на PHP 5.3, распространяется под лицензией MIT и доступен на github .

Первые коммиты были сделаны апреле 2011 года и на сегодняшний день Composer находится в стадии «alpha3». Однако, он уже достаточно стабилен и используется многими популярными PHP проектами (например, Symfony 2 ). Список проектов использующих Composer можно посмотреть на сайте packagist.org - это официальный репозиторий Composer пакетов. Кстати, на недавней конференции Devconf 2012 разработчик фреймворка Yii в своём докладе упомянул, что Yii2 скорее всего тоже будет использовать Composer.

В этой статье я кратко опишу основные возможности Composer и мы попробуем создать демонстрационный проект использующий Composer для загрузки необходимых библиотек. Все примеры будут доступны на github.com и bitbucket.org.

Что умеет Composer?

• Скачивать пакеты и их зависимости;
• по умолчанию, пакеты скачиваются из официального репозитория packagist.org. Любой человек может свободно добавить туда свой пакет, чтобы сделать его установку максимально лёгкой и удобной для всего мира;
• пакеты можно скачивать не только с packagist.org, но и из любого git, mercurial или svn репозитория;
• при скачивании пакетов с github.com или bitbucket.org не требуется установленной системы контроля версий (git или hg), Composer работает через API этих сайтов;
• git/hg/svn репозиторий с пакетом может находиться не только на одном из перечисленных выше сайтов, но в любом другом месте, например, в локальной сети предприятия или вообще на локальном жестком диске;
• кроме того, устанавливаемая библиотека не обязательно должна быть оформлена в виде Composer-пакета, вы можете сделать установку из любого git/hg/svn репозитория произвольной структуры;
• наконец, устанавливаемый пакет не обязательно должен быть git/hg/svn репозиторием, это может быть произвольный zip файл доступный по любому uri!
• все пакеты устанавливаются в текущую директорию (откуда была выполнена команда install), это позволяет иметь несколько различных версий библиотек при работе над разными проектами параллельно;
• команда update обновляет все установленные (или установит заново случайно удалённые) пакеты до свежих версий. А может и не обновлять версии до самых свежих, если создать специальный composer.lock файл - это позволяет зафиксировать комбинацию из стабильных версий всех используемых в проекте библиотек;
• после установки пакетов автоматически генерируется autoload.php, с помощью которого можно подключить установленные библиотеки в коде вашего проекта. При подготовке Composer-пакета рекомендуется использовать PSR-0 - стандарт расположения и именования php файлов, чтобы autoload смог их легко найти. В любом случае, автор пакета может описать правила, по которым autoload будет искать файлы тех или иных классов или неймспейсов. Если вы устанавливаете библиотеку, которая не оформлена как Composer-пакет (например, произвольный git репозиторий с github), то задача описания правил autoload ложится на ваши плечи. Так что никакой магии с генерируемым autoload.php нет - он умеет загружать всё (даже библиотеки с набором функций вне классов), главное, чтобы были описаны правила (автором библиотеки или вами).

Рабочий пример: используем Composer в своём проекте

Чтобы разобраться, как пользоваться Composer"ом, напишем маленький проектик на PHP: «Super Hello World». Поскольку мы не хотим изобретать велосипед и писать код «с нуля», возьмём готовые библиотеки и фреймворки.

Мы будем использовать cледующие библиотеки:

1. микрофреймворк Silex
2. шаблонизатор Twig (доступен в виде Composer пакета на packagist.org),
3. наш собственный логер посещений SuperLogger , который я оформил в виде Composer-пакета и опубликовал на github
4. нашу старую, но любимую легаси-библиотеку superlib , которая состоит из мешанины классов без неймспейсов и функций без классов; библиотека опубликована на github, но не является оформленным Composer-пакетом

Как мы это делали раньше: скачивали нужные нам фреймворки и библиотеки, думали куда их распаковать, писали в проекте кучу require (или require_once для надёжности).

Как мы это сделаем теперь: используем Composer - он сам скачает все библиотеки и сгенерирует для нас autoload.php. Кроме того, если мы захотим показать «Super Hello World» коллегам, достаточно будет опубликовать код нашего проекта на github (или ещё где-нибудь), не включая всех требуемых библиотек в репозиторий и не готовя длинной инструкции по их установке. Нашим коллегам достаточно будет скачать (склонировать) «Super Hello World» и выполнить команду
php composer.phar install
Composer распространяется в виде одного файла composer.phar (phar - это php-архив) - по сути это PHP скприт, который может принимать несколько команд (install, update, ...) и умеет скачивать и распаковывать библиотеки.

Кстати, немного о синтаксисе запуска.
Если вы работаете под Windows, то скорее всего вы будете писать что-то вроде
php C:\path\to\composer.phar install
Можно упростить себе жизнь, создав composer.bat и положив его в %PATH%.

В Linux и OS X можно настроить на исполнение команду типа
composer install

composer.json

Итак, мы готовы написать наш Super Hello World проект. И я его только что написал: http://github.com/pqr/superhelloworld . Код состоит из одного index.php файла в директории web и шаблона layout.twig в директории views.

Голова всему - это файл composer.json . Он должен быть в корне проекта, в нашем случае рядом с директориями web и view. В этом файле необходимо указать от каких библиотек зависит наш проект. Кроме того, если эти библиотеки не являются оформленными Composer-пакетами, то нужно указать некоторую дополнительную информацию об устанавливаемой библиотеке (например, описать правила автозагрузки классов и функций для autoload.php).

Composer.json, как вы догадались, имеет формат данных JSON. На вопрос "почему именно JSON? " разработчики Composer отвечают "Потому что. Просто примите это. ".

Нам нужно описать один js-объект, в котором будут находиться все инструкции. Первая и самая главная инструкция: require .

Подключаем пакеты с сайта packagist.org

{ "require": { "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev" } }
Здесь я описал зависимость проекта от PHP версии 5.3.0 и выше, от silex (микрофреймворк) и от twig (шаблонизатор). Silex и Twig доступны в виде Composer-пакетов на сайте packagist.org, поэтому дополнительных настроек не требуют. Замечу, что Silex в свою очередь зависит ещё от нескольких пакетов - все они будут скачены и установлены автоматически.

Имя пакета состоит из двух частей разделёных косой чертой: названия поставщика (vendor name) и названия библиотеки . Названием поставщика зачастую является ник автора или имя компании. Иногда, название поставщика совпадает с именем самой библиотеки или фреймворка.

Для каждого пакета обязательно нужно указать номер версии. Это может быть бранч в репозитории, например, «dev-master» - приставка dev сигнализирует, что это имя бранча, а сам бранч соответсвенно называется «master». Для mercurial репозитория аналогичная запись будет выглядеть как «dev-default». В качестве номера версии можно указать и более сложные правила, используя операторы сравнения. Кстати, если вы скачиваете код из удалённого репозитория, то Composer сканирует теги и имена веток в этом репозитории на предмет чего-то похожего на номера версий, например тег «v1.2.3» будет использован как указатель на версию 1.2.3.

Подключаем на собственный Compsoer-пакет

Далее, подключим наш собственный пакет SuperLogger, который правильно оформлен, но опубликован не на packagist.org, а на github:
{ "require": { "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" } ] }
Чтобы Composer знал где искать пакет «mycompany/superlogger», мы добавили массив repositories со ссылкой на соотвествующий github репозиторий. Обратим внимание, что записи в массиве repositories напрямую никак не связаны с блоком require - между пакетами и репозиториями не указано соответствие. На сколько я понял, Composer ищет все требуемые пакеты во всех указанных репозиториях (в т.ч. на сайте packagist.org) и скачивает найденные совпадения по каким-то внутренним приоритетам. Более глубоко я в этом моменте ещё не разбирался, поправьте меня, если кто-то знает детали.

Подключаем произвольный git репозиторий

Теперь подключим нашу легаси-библиотеку superlib, которая лежит на github, но не является оформленным Composer-пакетом, т.к. она очень старая.
{ "require":{ "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master", "pqr/superlib":"1.2.3" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" }, { "type":"package", "package":{ "name":"pqr/superlib", "version":"1.2.3", "source":{ "type":"git", "url":"http://github.com/pqr/superlib", "reference":"master" }, "autoload":{ "classmap":["timer.php"], "files":["lib_functions.php"] } } } ] }
В массив repositories добавился объект, который целиком описывает пакет pqr/superlib. По сути, это то описание, которое должен был бы сделать автор библиотеки и положить его внутри своего репозитория. Но по условиям задачи, superlib не является оформленным Composer-пакетом, поэтому нам пришлось создать его описание в рамках Super Hello World проекта. Аналогичным образом можно подключить любую другую библиотеку, в т.ч. простой zip файл.

Подключаем простой zip файл

Например, вот как могло бы выглядеть описание зависимости от шаблонизатора Smarty, распространяемого в виде zip файла с исходниками в svn:
{ "repositories":[ { "type":"package", "package":{ "name":"smarty/smarty", "version":"3.1.7", "dist":{ "url":"http://www.smarty.net/files/Smarty-3.1.7.zip", "type":"zip" }, "source":{ "url":"http://smarty-php.googlecode.com/svn/", "type":"svn", "reference":"tags/Smarty_3_1_7/distribution/" } } } ], "require":{ "smarty/smarty":"3.1.*" } }

Инстукция autoload

Вернёмся к нашему проекту.
Описывая «pqr/superlib», мы добавили инструкцию autoload . В ней указан файл timer.php, в котором будущий автозагрузчик будет искать классы и указали файл с функциями lib_functions.php - он будет принудительно подключаться в начале autoload.php.

Итак, наш проект состоит из:

• в корне лежит файл composer.json;
• в корне находятся директории web и views;
• внутри директории web лежит файл с «бизнес-логикой» нашего приложения: index.php;
• внутри директории views лежит файл шаблона layout.twig;
• дополнительно, в папку web я положил.htaccess (для apache) и web.config (для IIS 7.5) с правилами mod_rewrite/url rewriter - непосредсвенно к настройке Composer они отношения не имеют.

Всё готово к запуску.

Запускаем composer install

php composer.phar install
Composer клонирует репозитории и распаковывает их на нужной версии в директорию vendor , которую он сам создаёт в корне проекта. После распаковки, в директории vendor мы найдём:

• файл autoload.php
• служебные директории.composer и composer
• pimple - пакет, который подтянулся вместе с микрофреймворком Silex
• silex - сам микрофреймворк, его мы явным образом затребовали при описании зависимостей
• symfony - некоторые компоненты из Symfony 2, которые требуются для работы Silex
• twig - шаблонизатор, который мы также явно запросили
• mycompany - внутри этой директории будет находиться репозиторий superlogger скаченный с github
• pqr - внутри этой директории будет находиться репозиторий superlib, также скаченный с github

Остаётся только подключить autoload.php в начале файла web/index.php (require "../vendor/autoload.php") и все библиотеки и функции будут доступны!

Как создать собственный Composer пакет?

В этом проекте мы использовали Composer с точки зрения потребителя библиотек. А как самому создать Composer пакет, чтобы любой другой человек смог им воспользоваться?

На самом деле, один из таких пакетов я создал, когда подготавливал примеры для этой статьи. В корне репозитория superlogger лежит файл composer.json похожей структуры, который описывает сам пакет и его зависимости (в случае с superlogger зависимостей нет). Другие примеры: репозитории silex и twig, которые скачались в папку vendor - все они имеют файл composer.json в корне - смотрите, изучайте!

И, конечно, не забывайте про документацию на официальном сайте getcomposer.org/doc/ .
Эту тему я оставлю вам для самостоятельной проработки.

Подведём итоги

В этой статье я рассказал, что такое Composer, его историю и описал основные возможности. Мы с вами попробовали создать проект, который использует Composer для установки пакетов с сайта packagist.org и из наших собственных репозиториев.

Самое время попробовать!

1. Скачате Composer (getcomposer.org/download/)
2. Скачате superhelloworld (git clone git://github.com/pqr/superhelloworld.git)
3. Установите зависимости (cd superhelloworld && php composer.phar install)
4. Изучите появившуюся папку vendor и сгенерированный autoload.php
5. Используте Composer в своих проектах
   …
6. PROFIT!!!

На добавку пара ссылок

От автора: Очень часто при разработке веб-приложений, особенно крупных веб-проектов, необходимо использовать различные сторонние библиотеки. К примеру, это может быть php-фреймворк, либо шаблонизатор, либо движок форума, или все эти компоненты вместе. В данном уроке мы с Вами рассмотрим менеджер зависимостей Composer, при помощи которого можно легко скачать и установить необходимые библиотеки

Если мы используем несколько сторонних библиотек, все их необходимо правильно установить и подключить к разрабатываемому скрипту. В лучшем случае у каждой библиотеки – необходимо подключить один главный файл, при этом, если мы используем три сторонних библиотеки, значит необходимо подключить три файла.

Но что если одна из библиотек зависит по своему функционалу, еще от дополнительных библиотек, в этом случае их так же нужно скачивать и подключать. То есть при использовании нескольких библиотек возникают некоторые неудобства связанные с их установкой.

Поэтому в данном уроке мы с Вами рассмотрим менеджер зависимостей Composer, при помощи которого можно легко скачать и установить необходимые библиотеки.

Установка Composer

Composer – это менеджер зависимостей для интерпретатора языка PHP, если сказать проще – это скрипт, написанный на языке PHP, который скачивает необходимые Вам библиотеки, и автоматически формирует единственный специальный файл, подключив который, Вы подключите все скачанные библиотеки. При этом если необходимые Вам библиотеки зависят от некоторых дополнительных библиотек – они так же будут скачаны автоматически. Скачивание библиотек, осуществляется с официального репозитория пакетов packagist.org.

Как я сказал ранее Composer — это менеджер зависимостей для интерпретатора языка PHP, а значит устанавливается данный инструмент непосредственно в интерпретатор данного языка. При этом, сейчас мы с Вами говорим о интерпретаторе, который установлен на Вашем домашнем компьютере, потому как зачастую, на сервере (на реальном хостинге в интернете) у нас нет доступа к интерпретатору языка PHP. Да и это вовсе не нужно, так как в основном скрипты разрабатываются на домашнем компьютере и переносятся на хостинг по окончанию работы. Конечно, интерпретатор языка PHP у всех может быть установлен по разному, к примеру кто то использует программное обеспечение Denwer, кто то OpenServer, кто отдельную установку PHP, Apache, Mysql, но это совсем не важно так как процесс установки менеджера зависимостей Composer аналогичен для всех случаев.

Перед установкой, давайте ознакомимся с официальным сайтом менеджера зависимостей Composer — https://getcomposer.org/ :

Здесь на странице Documentation приведено подробное описание по установке и работе с данным менеджером (правда, на английском языке).

Composer можно установить на операционную систему Windows двумя способами:

вручную, используя командную строку;

автоматически, используя специальный файл, ссылку на который Вы найдете на странице документации, в разделе установки под ОС Windows.

В данном уроке мы с Вами рассмотрим ручной способ установки инструмента Composer. Сразу же хотел бы отметить, что Сomposer, представляет собой файл composer.phar, который обычно располагается в папке с интерпретатором языка PHP. Поэтому перед установкой желательно просмотреть данную папку, потому как, к примеру в программном обеспечении OpenServer (в модулях PHP), Composer уже установлен.

Итак, запустив веб-сервер, открываем командную строку (напомню, что для Windows 7 командную строку можно открыть, если в поиске меню Пуск ввести cmd), и переходим в папку, в которую установлен интерпретатор языка PHP. Для этого используется команда cd: cd путь к папке

Теперь в соответствии с документацией, необходимо выполнить следующую команду: php -r «readfile(‘https://getcomposer.org/installer’);» | php

Которая, выполнит PHP код readfile(‘https://getcomposer.org/installer’), то есть мы прочитаем удаленный файл. Здесь хотел бы отметить, что в Вашем интерпретаторе, языка PHP, должно быть подключено расширение php_openssl.dll, иначе команда не выполнится.

После выполнения команды мы видим сообщение о том, что установка успешно завершена. Проверить, действительно ли был установлен Composer, можно используя команду, которая покажет его версию: php composer.phar -v

Теперь для удобства работы с ним, давайте выполним еще одну команду: echo @php «%~dp0composer.phar» %*>composer.bat

Данная команда, создаст в папке интерпретатора языка PHP, специальный файл composer.bat, при помощи которого, можно обращаться к менеджеру зависимостей, используя только имя composer, и при этом, находясь в любой папке из под командной строки. Но при этом в системной переменной path, необходимо прописать путь к папке, в которую установлен интерпретатор языка PHP:

Установка необходимых библиотек

Для начала давайте условимся, что для нашего скрипта потребуются следующие библиотеки:

Теперь, необходимо в специальном файле composer.json (данный файл создаем в папке с разрабатываемым скриптом) описать, что вышеперечисленные библиотеки необходимы для работы будущего скрипта:

{ "require": { "slim/slim":"2.*", "twig/twig":"~1.0", "phpbb/phpbb": "3.1.3-RC2" } }

"require" : { "slim/slim" : "2.*" , "twig/twig" : "~1.0" , "phpbb/phpbb" : "3.1.3-RC2"

Как Вы видите, данный файл должен содержать объект в виде json строки. У которого, в свойстве require, описаны те библиотеки, от которых зависит будущий скрипт. Причем, require – это в свою очередь так же объект, свойства которого и есть те библиотеки, которые необходимо скачать. Где имя свойства — это название библиотеки, а значение – это версия скачиваемой библиотеки. Причем название состоит из двух подстрок, разделенных /. Строка до разделителя – это имя поставщика, строка после – это название библиотеки.

Названия и версии библиотек, которые необходимо указывать в файле composer.json, приводятся на официальных сайтах, в разделе установка. К примеру, для шаблонизатора Twig, в документации, в разделе Installation, приведена строка, которую я вписал в файл composer.json:

После составления файла composer.json, открываем командную строку, переходим в папку, разрабатываемого скрипта, и выполняем команду: composer install

И сразу же запускается установка необходимых библиотек.

После установки, в папке разрабатываемого скрипта, мы найдем папку vendor, в которую были скачаны все необходимые библиотеки и их зависимости, а так же был сгенерирован файл autoload.php, подключив который Вы подключите все скачанные библиотеки. После этого можно работать с установленными библиотеками.

На этом данный урок завершен. Всего Вам доброго и удачного кодирования!

) - это относительно новый и уже достаточно популярный менеджер зависимостей для PHP. Вы можете описать от каких библиотек зависит ваш проект и Composer установит нужные библиотеки за вас! Причём Composer - это не менеджер пакетов в классическом понимании. Да, он оперирует с сущностями, которые мы будем называть «пакетами» или библиотеками, но устанавливаются они внутрь каждого проекта отдельно, а не глобально (это одно из основных отличий от старого-доброго PEAR).

Кратко, как это работает:

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

При создании Composer авторы черпали идеи и вдохновение из аналогичных проектов: npm для Node.js и Bundler для Ruby.

Изначально он был спроектирован и разработан двумя людьми Nils Adermann и Jordi Boggiano , сейчас в проекте участвует более двадцати контрибьюторов, Проект написан на PHP 5.3, распространяется под лицензией MIT и доступен на github .

Первые коммиты были сделаны апреле 2011 года и на сегодняшний день Composer находится в стадии «alpha3». Однако, он уже достаточно стабилен и используется многими популярными PHP проектами (например, Symfony 2 ). Список проектов использующих Composer можно посмотреть на сайте packagist.org - это официальный репозиторий Composer пакетов. Кстати, на недавней конференции Devconf 2012 разработчик фреймворка Yii в своём докладе упомянул, что Yii2 скорее всего тоже будет использовать Composer.

В этой статье я кратко опишу основные возможности Composer и мы попробуем создать демонстрационный проект использующий Composer для загрузки необходимых библиотек. Все примеры будут доступны на github.com и bitbucket.org.

Что умеет Composer?

• Скачивать пакеты и их зависимости;
• по умолчанию, пакеты скачиваются из официального репозитория packagist.org. Любой человек может свободно добавить туда свой пакет, чтобы сделать его установку максимально лёгкой и удобной для всего мира;
• пакеты можно скачивать не только с packagist.org, но и из любого git, mercurial или svn репозитория;
• при скачивании пакетов с github.com или bitbucket.org не требуется установленной системы контроля версий (git или hg), Composer работает через API этих сайтов;
• git/hg/svn репозиторий с пакетом может находиться не только на одном из перечисленных выше сайтов, но в любом другом месте, например, в локальной сети предприятия или вообще на локальном жестком диске;
• кроме того, устанавливаемая библиотека не обязательно должна быть оформлена в виде Composer-пакета, вы можете сделать установку из любого git/hg/svn репозитория произвольной структуры;
• наконец, устанавливаемый пакет не обязательно должен быть git/hg/svn репозиторием, это может быть произвольный zip файл доступный по любому uri!
• все пакеты устанавливаются в текущую директорию (откуда была выполнена команда install), это позволяет иметь несколько различных версий библиотек при работе над разными проектами параллельно;
• команда update обновляет все установленные (или установит заново случайно удалённые) пакеты до свежих версий. А может и не обновлять версии до самых свежих, если создать специальный composer.lock файл - это позволяет зафиксировать комбинацию из стабильных версий всех используемых в проекте библиотек;
• после установки пакетов автоматически генерируется autoload.php, с помощью которого можно подключить установленные библиотеки в коде вашего проекта. При подготовке Composer-пакета рекомендуется использовать PSR-0 - стандарт расположения и именования php файлов, чтобы autoload смог их легко найти. В любом случае, автор пакета может описать правила, по которым autoload будет искать файлы тех или иных классов или неймспейсов. Если вы устанавливаете библиотеку, которая не оформлена как Composer-пакет (например, произвольный git репозиторий с github), то задача описания правил autoload ложится на ваши плечи. Так что никакой магии с генерируемым autoload.php нет - он умеет загружать всё (даже библиотеки с набором функций вне классов), главное, чтобы были описаны правила (автором библиотеки или вами).

Рабочий пример: используем Composer в своём проекте

Чтобы разобраться, как пользоваться Composer"ом, напишем маленький проектик на PHP: «Super Hello World». Поскольку мы не хотим изобретать велосипед и писать код «с нуля», возьмём готовые библиотеки и фреймворки.

Мы будем использовать cледующие библиотеки:

1. микрофреймворк Silex
2. шаблонизатор Twig (доступен в виде Composer пакета на packagist.org),
3. наш собственный логер посещений SuperLogger , который я оформил в виде Composer-пакета и опубликовал на github
4. нашу старую, но любимую легаси-библиотеку superlib , которая состоит из мешанины классов без неймспейсов и функций без классов; библиотека опубликована на github, но не является оформленным Composer-пакетом

Как мы это делали раньше: скачивали нужные нам фреймворки и библиотеки, думали куда их распаковать, писали в проекте кучу require (или require_once для надёжности).

Как мы это сделаем теперь: используем Composer - он сам скачает все библиотеки и сгенерирует для нас autoload.php. Кроме того, если мы захотим показать «Super Hello World» коллегам, достаточно будет опубликовать код нашего проекта на github (или ещё где-нибудь), не включая всех требуемых библиотек в репозиторий и не готовя длинной инструкции по их установке. Нашим коллегам достаточно будет скачать (склонировать) «Super Hello World» и выполнить команду
php composer.phar install
Composer распространяется в виде одного файла composer.phar (phar - это php-архив) - по сути это PHP скприт, который может принимать несколько команд (install, update, ...) и умеет скачивать и распаковывать библиотеки.

Кстати, немного о синтаксисе запуска.
Если вы работаете под Windows, то скорее всего вы будете писать что-то вроде
php C:\path\to\composer.phar install
Можно упростить себе жизнь, создав composer.bat и положив его в %PATH%.

В Linux и OS X можно настроить на исполнение команду типа
composer install

composer.json

Итак, мы готовы написать наш Super Hello World проект. И я его только что написал: http://github.com/pqr/superhelloworld . Код состоит из одного index.php файла в директории web и шаблона layout.twig в директории views.

Голова всему - это файл composer.json . Он должен быть в корне проекта, в нашем случае рядом с директориями web и view. В этом файле необходимо указать от каких библиотек зависит наш проект. Кроме того, если эти библиотеки не являются оформленными Composer-пакетами, то нужно указать некоторую дополнительную информацию об устанавливаемой библиотеке (например, описать правила автозагрузки классов и функций для autoload.php).

Composer.json, как вы догадались, имеет формат данных JSON. На вопрос "почему именно JSON? " разработчики Composer отвечают "Потому что. Просто примите это. ".

Нам нужно описать один js-объект, в котором будут находиться все инструкции. Первая и самая главная инструкция: require .

Подключаем пакеты с сайта packagist.org

{ "require": { "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev" } }
Здесь я описал зависимость проекта от PHP версии 5.3.0 и выше, от silex (микрофреймворк) и от twig (шаблонизатор). Silex и Twig доступны в виде Composer-пакетов на сайте packagist.org, поэтому дополнительных настроек не требуют. Замечу, что Silex в свою очередь зависит ещё от нескольких пакетов - все они будут скачены и установлены автоматически.

Имя пакета состоит из двух частей разделёных косой чертой: названия поставщика (vendor name) и названия библиотеки . Названием поставщика зачастую является ник автора или имя компании. Иногда, название поставщика совпадает с именем самой библиотеки или фреймворка.

Для каждого пакета обязательно нужно указать номер версии. Это может быть бранч в репозитории, например, «dev-master» - приставка dev сигнализирует, что это имя бранча, а сам бранч соответсвенно называется «master». Для mercurial репозитория аналогичная запись будет выглядеть как «dev-default». В качестве номера версии можно указать и более сложные правила, используя операторы сравнения. Кстати, если вы скачиваете код из удалённого репозитория, то Composer сканирует теги и имена веток в этом репозитории на предмет чего-то похожего на номера версий, например тег «v1.2.3» будет использован как указатель на версию 1.2.3.

Подключаем на собственный Compsoer-пакет

Далее, подключим наш собственный пакет SuperLogger, который правильно оформлен, но опубликован не на packagist.org, а на github:
{ "require": { "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" } ] }
Чтобы Composer знал где искать пакет «mycompany/superlogger», мы добавили массив repositories со ссылкой на соотвествующий github репозиторий. Обратим внимание, что записи в массиве repositories напрямую никак не связаны с блоком require - между пакетами и репозиториями не указано соответствие. На сколько я понял, Composer ищет все требуемые пакеты во всех указанных репозиториях (в т.ч. на сайте packagist.org) и скачивает найденные совпадения по каким-то внутренним приоритетам. Более глубоко я в этом моменте ещё не разбирался, поправьте меня, если кто-то знает детали.

Подключаем произвольный git репозиторий

Теперь подключим нашу легаси-библиотеку superlib, которая лежит на github, но не является оформленным Composer-пакетом, т.к. она очень старая.
{ "require":{ "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master", "pqr/superlib":"1.2.3" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" }, { "type":"package", "package":{ "name":"pqr/superlib", "version":"1.2.3", "source":{ "type":"git", "url":"http://github.com/pqr/superlib", "reference":"master" }, "autoload":{ "classmap":["timer.php"], "files":["lib_functions.php"] } } } ] }
В массив repositories добавился объект, который целиком описывает пакет pqr/superlib. По сути, это то описание, которое должен был бы сделать автор библиотеки и положить его внутри своего репозитория. Но по условиям задачи, superlib не является оформленным Composer-пакетом, поэтому нам пришлось создать его описание в рамках Super Hello World проекта. Аналогичным образом можно подключить любую другую библиотеку, в т.ч. простой zip файл.

Подключаем простой zip файл

Например, вот как могло бы выглядеть описание зависимости от шаблонизатора Smarty, распространяемого в виде zip файла с исходниками в svn:
{ "repositories":[ { "type":"package", "package":{ "name":"smarty/smarty", "version":"3.1.7", "dist":{ "url":"http://www.smarty.net/files/Smarty-3.1.7.zip", "type":"zip" }, "source":{ "url":"http://smarty-php.googlecode.com/svn/", "type":"svn", "reference":"tags/Smarty_3_1_7/distribution/" } } } ], "require":{ "smarty/smarty":"3.1.*" } }

Инстукция autoload

Вернёмся к нашему проекту.
Описывая «pqr/superlib», мы добавили инструкцию autoload . В ней указан файл timer.php, в котором будущий автозагрузчик будет искать классы и указали файл с функциями lib_functions.php - он будет принудительно подключаться в начале autoload.php.

Итак, наш проект состоит из:

• в корне лежит файл composer.json;
• в корне находятся директории web и views;
• внутри директории web лежит файл с «бизнес-логикой» нашего приложения: index.php;
• внутри директории views лежит файл шаблона layout.twig;
• дополнительно, в папку web я положил.htaccess (для apache) и web.config (для IIS 7.5) с правилами mod_rewrite/url rewriter - непосредсвенно к настройке Composer они отношения не имеют.

Всё готово к запуску.

Запускаем composer install

php composer.phar install
Composer клонирует репозитории и распаковывает их на нужной версии в директорию vendor , которую он сам создаёт в корне проекта. После распаковки, в директории vendor мы найдём:

• файл autoload.php
• служебные директории.composer и composer
• pimple - пакет, который подтянулся вместе с микрофреймворком Silex
• silex - сам микрофреймворк, его мы явным образом затребовали при описании зависимостей
• symfony - некоторые компоненты из Symfony 2, которые требуются для работы Silex
• twig - шаблонизатор, который мы также явно запросили
• mycompany - внутри этой директории будет находиться репозиторий superlogger скаченный с github
• pqr - внутри этой директории будет находиться репозиторий superlib, также скаченный с github

Остаётся только подключить autoload.php в начале файла web/index.php (require "../vendor/autoload.php") и все библиотеки и функции будут доступны!

Как создать собственный Composer пакет?

В этом проекте мы использовали Composer с точки зрения потребителя библиотек. А как самому создать Composer пакет, чтобы любой другой человек смог им воспользоваться?

На самом деле, один из таких пакетов я создал, когда подготавливал примеры для этой статьи. В корне репозитория superlogger лежит файл composer.json похожей структуры, который описывает сам пакет и его зависимости (в случае с superlogger зависимостей нет). Другие примеры: репозитории silex и twig, которые скачались в папку vendor - все они имеют файл composer.json в корне - смотрите, изучайте!

И, конечно, не забывайте про документацию на официальном сайте getcomposer.org/doc/ .
Эту тему я оставлю вам для самостоятельной проработки.

Подведём итоги

В этой статье я рассказал, что такое Composer, его историю и описал основные возможности. Мы с вами попробовали создать проект, который использует Composer для установки пакетов с сайта packagist.org и из наших собственных репозиториев.

Самое время попробовать!

1. Скачате Composer (getcomposer.org/download/)
2. Скачате superhelloworld (git clone git://github.com/pqr/superhelloworld.git)
3. Установите зависимости (cd superhelloworld && php composer.phar install)
4. Изучите появившуюся папку vendor и сгенерированный autoload.php
5. Используте Composer в своих проектах
   …
6. PROFIT!!!

На добавку пара ссылок