Что это и зачем оно мне надо?
Если у тебя возник этот вопрос, тогда не читай дальше статью и сперва спроси у google “что такое dependency injection?” и зачем тебе нужен dependency manager (в частности composer).
Лично у меня уже не существует приложений без composer-а. Особенно при разработке под фреймворк. Вот лишь коренные преимущества использования менеджера зависимостей в проектах:
- Удобная установка и обновление сторонних пакетов и библиотек
- Правильный деплоймент
- Чужой код от сторонних пакетов не коммитится в свой репозиторий, и не мусорит код и статистику
- Гибкое управление версиями зависимостей
Установка
Тут все максимально просто, но сперва надо определиться с методом использования: один composer для всего localhost-а или каждому проекту свой composer? (можно конечно и комбинировать)
Первый вариант удобен разработчикам которые одновременно трудятся над множеством приложений и все держат в чистоте и свежести. Второй вариант используется при требовании от приложения иметь точную и единую версию composer-а у всех разработчиков, и тут он коммитится в репозиторий.
Держим Composer вместе с приложением
Достаточно скачать файл composer.phar в корневую директорию нашего приложения. Легче будет сделать это командой ниже.
curl -sS https://getcomposer.org/installer | php
Дополнительно сделаем возможным непосредственный запуск самого phar файла. В этом случае мы получим удобный запуск “./composer.phar” вместо “php composer.phar” (имхо это удобнее).
sudo chmod +x composer.phar
Далее либо докачиваем с его помощью скелет для нового приложения от любимого фреймворка, либо собираем собственный composer.json руками. Пример первого есть в статье про установку скелетона Zend Framework 2, а формат json-файла рассмотрим ниже.
Единый Composer для всего localhost (доступен отовсюду)
Опять же качаем composer.phar (но уже не важно куда).
curl -sS https://getcomposer.org/installer | php
Потом переносим его в удобный для нас bin чтобы система автоматически связывала имя файла как альяс для команды, выдаем права на запуск и определяем своего пользователя как владельца.
sudo mv composer.phar /usr/local/bin/composer sudo chmod +x /usr/local/bin/composer sudo chown developer:developer /usr/local/bin/composer
Вот и вся магия. Теперь где угодно можно вызвать команду composer. Ура!
Конфигурация Composer
{
"name": "My Project",
"description": "Project description",
"homepage": "http://my-project.com/",
"require": {
"php": ">=5.3.3",
"zendframework/zendframework": "2.*"
},
"require-dev": {
"zendframework/zftool": "v0.1.0",
"zendframework/zend-developer-tools": "dev-master"
}
}
Формат composer.json хорошо описан в официальной документации.
Команды Composer
install
Установив composer и собрав свой composer.json можно приступить к установке тех самых пакетов которые мы указали в своем json-файле в блоке “require” и “require-dev”. Для этого мы используем команду install.
composer install ./composer.phar install php composer.phar install
* Первая команда (строка 1) для тех кто выбрал метод установки единого composer для всей операционной системы. Вторая и третья нужны всем остальным и отличаются лишь тем, дали вы права на запуск phar-файла либо нет.
При первом запуске команды install мы получим последнюю либо точную версию всех пакетов которые мы указали в json-файле (в зависимости от того как мы указали версию для каждого отдельного пакета). Повторный запуск команды install ни к чему не приведет – и это важный момент!
Во время исполнения install, composer скачает все библиотеки в папку vendor нашего проекта (ниже опишу как сменить этот путь), а рядом с json-файлом будет создан новый файл composer.lock (это снепшот – слепок установленных пакетов с указанием их точных версий). Папку vendor стоит сразу же поместить в .gitignore, дабы случайно не смешать все со своим кодом. А вот lock-файл наоборот, нужно закомитить и отправить в репозиторий. Если удалить папку vendor или некоторые пакеты из него а потом опять вызвать команду install, то все пакеты будут восстановлены с точно теми же версиями которые были установлены при первом вызове install. Так происходит, потому что composer проверяет наличие lock-файла, и при его наличии игнорирует версии пакетов указанные в json-файле (только если те не были спущены!), и устанавливает версии указанные в lock-файле.
Таким образом, передавая единый lock-файл между всеми разработчиками, команда будет гарантировано иметь одинаковые версии пакетов (думаю не стоит пояснять зачем).
update
При необходимости же обновить версии пакетов до актуальных – вызываем команду update.
composer update ./composer.phar update php composer.phar update
После чего все пакеты будут обновлены. Так же будет обновлен и lock-файл.
Тут стоит помнить что обновляться пакеты будут в соответствии с форматом версии указанным для каждого из них отдельно в json-файле. Синтаксис указания версий для пакетов хорошо описан в официальной документации.
self-update
Еще одна полезная команда, которая обновит сам composer.
composer self-update ./composer.phar self-update php composer.phar self-update
show
./composer.phar show -s -t ./composer.phar show -i -t
Эта команда отображает список установленных пакетов.
Первый пример (с ключом -s) отобразит дерево пакетов которые мы сами руками указали в json-файле.
Второй пример (с ключом -i) отобразит абсолютно все установленные пакеты, рекурсивно включая зависимости всех наших первоначальных пакетов.
Ключ -t меняет отображение ответа в стиль дерева зависимостей.
vendor path или как сменить путь установки библиотек
Для изменения пути установки пакетов, необходимо использовать директиву vendor-dir в json-файле. Вот пример:
{
"name": "My Project",
"description": "Project description",
"homepage": "http://my-project.com/",
"config": {
"vendor-dir": "/vendor/custom/path"
},
"require": {
"php": ">=5.3.3",
"zendframework/zendframework": "2.*"
},
"require-dev": {
"zendframework/zftool": "v0.1.0",
"zendframework/zend-developer-tools": "dev-master"
}
}
Заключение
Я постарался описать все основное что может понадобится для знакомства с Composer-ом. Более глубокие фичи лучше изучать по документации. Например: как подключить загрузку собственной библиотеки с github.
А для удобного поиска необходимых пакетов советую пользоваться проектом packagist.org
Если же возникнут вопросы, смело пишите в комментарии.
Google+