Установка Composer для “чайников” (настройка и базовые команды). Автозагрузка классов с помощью Composer Подключаем простой zip файл

В этом посте я расскажу о личных впечатлениях от использования такой интересной штуки, как . Если кто не в курсе, это менеджер зависимостей для PHP библиотек, который облегчает установку, обновление и поддержку различных библиотек в вашем проекте.Программисту для комфортной работы нужна инфраструктура (это я вам точно говорю:-). Это и удобное кресло, мощная машина с двумя мониторами, и совеременная IDE, средства работы с базами данных, инструменты отладки. Но кроме того важна инфраструктура разработки самого проекта.

Возьмём к примеру Ruby. Этот язык, блин, ну просто законодатель мод в сфере веб-дева. Там и удобные инструменты скаффолдинга (ну в ZF это тоже есть), и такие штуки, как rake для выполнения задач. Я уж не говорю про миграции, юнит-тесты со всяческими mock-объектами. Когда я кодил на Ruby ощущение было сродни тому, что сидишь в комфортабельном кресле в бизнес-классе в самолете и единственной твоей проблемой является выбор напитка под настроение.

Шучу-шучу. Не всё так радужно в Ruby Есть куча кривых гемов, разработчики иногда выпускают такооое чудо, что мама не горюй. Я уж молчу про низкоуровневое шаманство, когда надо сделать что-то типа распределённой или многопоточной системы. Но речь в посте будет не об этом. А о том, что в Ruby есть такая штук, как RubyGems.

RubyGems это система для управления зависимостями в Ruby проекте. В частности есть такая штука как Bundler, который одним движением устанавливает нужные пакеты или обновляет их. Именно с него наглым образом был списан он послужил вдохновением для Composer.

Что умеет Composer

Итак, краткий обзор фич. Их всего две: управление пакетами и автозагрузка классов. Надо сказать, что без composer обе эти задачи отнимали достаточно много времени. Интернет до сих пор пестрит статьями в стиле «как связать ZF 1.x и Doctrine 2» или «как установить Doctrine 2 ODM и Doctrine 1 ORM». Извращение, скажет вы. Я спеуиально утрировал, но согласитесь, приходится довольно сильно заморачиваться чтобы скрестить некоторые фреймворки или библиотеки. С выходом Composer ситуация поменялась.

Отдельное спасибо надо сказать за человеческую автозагрузку. Ух сколько времени я когда-то потратил на интеграцию Zend_Loader_Autoloader и Doctrine/ClassLoader. Теперь это в прошлом. Садимся в кресло

Пример composer.json

Вот пример файла с описанием зависимостей из одного проекта.

{ "require": { "doctrine/common": "2.3.0", "doctrine/migrations": "dev-master", "doctrine/dbal": "2.3.0", "doctrine/orm": "2.3.0", "doctrine/mongodb": "1.0.x-dev", "doctrine/mongodb-odm": "1.0.x-dev", "simukti/zf1": "1.12.0", "zendframework/zendframework": "2.0.3" }, "autoload": { "psr-0": { "ZendExtra": "vendor/netandreus/zend-extra/lib/", "DoctrineExtra" : "vendor/netandreus/doctrine-extra/lib/", "MyProject": "vendor/myvendor/myproject/lib/", "Hydrators": "misc/cache/", "": "app/default/models/" } }

Итак, давайте пройдёмся построчно. В блоке require мы описываем название пакетов в виде vendorName/packageName и минимально необходимые версии для нашего проекта. Потом они будут сами скачиваться и устанавливаться в папку vendor. Как видите Доктрина например раскукожилась сразу в несколько пакетов. Кстати миграции в отдельный пакет выделились совсем недавно, так что следите за новостями проекта. Товарищу simukti выражаю огромную благодарность, за то что он портировал все последние версии ZF 1.x в composer. Когда мне в своё время он понадобился, я начал это делать… да так и не успел в связи с другими задачами. Сейчас же в рамках одного проекта у нас есть возможность использовать компоненты Doctrine 2 ODM + ORM + ZF 1.x + ZF 2.x. Сумасшедший винигрет, но нам он нужен. Т.к. мы потихоньку мигрируем с MySQL (да простит меня Michail Widenius) на MongoDB. Основной костяк — на ZF1, ну а ZF2 — тоже не из праздного любопытсята /* интрига */ .

Теперь вторая часть конфига — require. Тут мы задаём классы (вернее их неймспейсы) и места их хранения, т.е. разрешаем пути для соответствующих неймспейсов. Обратите внимание на несколько моментов. Для гидраторов доктрины (если вы не знаете что это, то можете пропустить) указываем пути, т.к. при отсутствующем автозагрузчике доктрины она не может их найти. Последняя строка — местоположение помойки, где могут лежать классы с любыми неймспейсами. Основная особенность Composer в том, что такая помойка (к счастью) может быть только одна. А вот в нашем проекте классы require’ились откуда попало, поэтому пришлось провести так сказать garbage collection и свалить всё в одну кучу. Придётся конечно когда-нибудь и её разобрать, но теперь по крайней месте весь мусор в одном месте. Ну а ZendExtra и DoctrineExtra — этомои расширения, котоыре я частично описывал в своих постах.

Баги Composer

Ну куда же без багов. Самый пожалуй замечатенльный баг . Когда вы, уверенные, что у вас всё ок, делаете php composer.phar update, вас ждёт … разочарование. Пробелема в том, что composer не выкачивает исходники (вернее не обновляет их) если указана dev ветка, и исходники старше 6 месяцев. К сожалению в моём composer.json такими оказались пакеты с доктриной. Решение простое, перед тем, как делать update удаляем пакеты с доктриной.

Второй баг был в том, что в репозитарийх некоторых пакетов лежит файл.gitignore, который выкачивается при update/install. А если потом исходники проекта (вместе с этим пакетом) закоммитить, то они не дойдёт. Например в assembla, с которйо я работаю появляется некий пустой файл вместо папки с сорцами. При этом коммит и пуш проходит нормально, а траварищи жалуются, что к ним ничего не прилетает. Решение простое, после Update стираем наифг файлы.gitignore из изходников с пакетами.

Использовать или нет Composer?

Да! Как сказал кто-то, ваша библиотека — отстой, если в её корне не лежит файл composer.json Не ну серьезно, прошли времена php 4, phpclasses, кучи автозагрузчиков в стеке. Давайте перестанем плодить говнокод, будем соблюдать стандарты (ну хотя бы psr-0) и писать так сказать код с человеческим лицом. Я всецело за унификацию и стандартизацию! Enjoy!

Спасибо!

Если вам помогла статья, или вы хотите поддержать мои исследования и блог - вот лучший способ сделать это:

Что это и зачем оно мне надо?

Если у тебя возник этот вопрос, тогда не читай дальше статью и сперва спроси у google “что такое dependency injection?” и зачем тебе нужен dependency manager (в частности ).

Лично у меня уже не существует приложений без composer-а. Особенно при разработке под фреймворк. Вот лишь коренные преимущества использования менеджера зависимостей в проектах:

  • Удобная установка и обновление сторонних пакетов и библиотек
  • Правильный деплоймент
  • Чужой код от сторонних пакетов не коммитится в свой репозиторий, и не мусорит код и статистику
  • Гибкое управление версиями зависимостей

Установка

Тут все максимально просто, но сперва надо определиться с методом использования: один composer для всего localhost-а или каждому проекту свой composer? (можно конечно и комбинировать)

Первый вариант удобен разработчикам которые одновременно трудятся над множеством приложений и все держат в чистоте и свежести. Второй вариант используется при требовании от приложения иметь точную и единую версию composer-а у всех разработчиков, и тут он коммитится в репозиторий.

Держим Composer вместе с приложением

Команды Composer

install

Установив и собрав свой composer.json можно приступить к установке тех самых пакетов которые мы указали в своем json-файле в блоке “require” и “require-dev”. Для этого мы используем команду install .

Composer install ./composer.phar install php composer.phar install

* Первая команда (строка 1) для тех кто выбрал метод установки единого для всей операционной системы. Вторая и третья нужны всем остальным и отличаются лишь тем, дали вы права на запуск phar-файла либо нет.

При первом запуске команды install мы получим последнюю либо точную версию всех пакетов которые мы указали в json-файле (в зависимости от того как мы указали версию для каждого отдельного пакета). Повторный запуск команды install ни к чему не приведет – и это важный момент!

Во время исполнения install скачает все библиотеки в папку vendor нашего проекта (ниже опишу как сменить этот путь), а рядом с json -файлом будет создан новый файл composer.lock (это снепшот – слепок установленных пакетов с указанием их точных версий). Папку vendor стоит сразу же поместить в .gitignore , дабы случайно не смешать все со своим кодом. А вот lock -файл наоборот, нужно закомитить и отправить в репозиторий. Если удалить папку vendor или некоторые пакеты из него а потом опять вызвать команду install , то все пакеты будут восстановлены с точно теми же версиями которые были установлены при первом вызове install . Так происходит, потому что проверяет наличие lock -файла, и при его наличии игнорирует версии пакетов указанные в json-файле (только если те не были спущены!), и устанавливает версии указанные в lock -файле.

Таким образом, передавая единый lock -файл между всеми разработчиками, команда будет гарантировано иметь одинаковые версии пакетов (думаю не стоит пояснять зачем).

update

При необходимости же обновить версии пакетов до актуальных – вызываем команду update .

Composer update ./composer.phar update php composer.phar update

После чего все пакеты будут обновлены. Так же будет обновлен и lock -файл.

Тут стоит помнить что обновляться пакеты будут в соответствии с форматом версии указанным для каждого из них отдельно в json -файле. Синтаксис указания версий для пакетов хорошо описан в официальной документации .

self-update

Еще одна полезная команда, которая обновит сам .

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

Если же возникнут вопросы, смело пишите в комментарии.

У меня знакомство с 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.*" } }

Composer - менеджер зависимостей для PHP (Dependency Manager for PHP) или пакетный менеджер (зависимости это пакеты - логически законченные сторонние или собственные наработки, использующиеся в проекте).

Установить лучше глобально. Для OSX в терминале вводим

Curl -sS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin/composer

Composer

Если всё правильно, то вы увидите список команд. Значит можно использовать composer.

1. Как создавать новый проект в composer?

Все зависимости composer хранит в файле composer.json, на вопрос "почему именно JSON?" разработчики Composer отвечают "Потому что. Просто примите это.".

Создать этот файл можно командой

Composer init (или php composer.phar init)

Композитор проведёт вас по нескольких шагам - название проекта, описание, лицензия. Для вас важен шаг, где composer просит указать пакет, который хотите установить. Он предложит поискать пакет (search for a package), где вы вводите, например, "yii" и поиск предлагает все пакеты для yii, имеющиеся на сайте packagist.org. Выбрав то, что вам надо composer создаст в папке вашего проекта файл composer.json, со всеми описанными зависимостями.

Теперь осталось их только установить командой:

Composer install

Все. Теперь в вашем проекте появилось все что вы хотели скачать.

2. Как создать проект из готового пакета через composer?

Делается это командой create-project ("Create new project from a package into given directory.") в папке, где хотите создать папку проекта.

Например возьмём пакет продвинутой заготовки для приложения на yii2 (https://packagist.org/packages/yiisoft/yii2-app-advanced). Значит этот пакет загрузили на packagist.org.

Composer create-project yiisoft/yii2-app-advanced yii2advanced 2.0.0-beta

yii2advanced - указываете название вашего проекта (папки на компьютере)
2.0.0-beta - версия (смотрим какие версии есть на packagist.org)

После этой команды composer скачивает пакет, и устанавливает все зависимости к нему (вам не надо искать по разным сайтам необходимые расширения - composer находит их сам).

3. Обновлять пакет.

Командой

(Updates your dependencies to the latest version according to composer.json, and updates the composer.lock file.) - обновляет все установленные (или установит заново случайно удалённые) пакеты до свежих версий. А может и не обновлять версии до самых свежих, если создать специальный composer.lock файл — это позволяет зафиксировать комбинацию из стабильных версий всех используемых в проекте библиотек;

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

Всем привет. Сегодня мы поговорим о том, что такое пакетные менеджеры , и рассмотрим один из них - composer .

Для начала разберемся, для чего нужны пакетные менеджеры ? Пакетные менеджеры помогают через консоль буквально в паре строк скачать все пакеты, зависимости, какие-то фреймворки, плагины, используемые языком программирования. В нашем случае composer - это пакетный менеджер для языка программирования php .

Чтобы показать вам, как работает composer, давайте скачаем фреймворк yii

Итак, зайдите на сайт http://getcomposer.org/ и нажмите кнопку "Getting Started" . Теперь нажмите Installation - *nix , чтобы установить его на Mac или Linux . Откройте терминал и вставьте следующие команды:

1) $ curl -sS https://getcomposer.org/installer | php

2) $ mv composer.phar /usr/local/bin/composer

После того, как вы все сделали, введите команду composer и, если у вас появилась большая надпись "COMPOSER" и некоторая информация, то вы все сделали правильно и composer успешно установился.

Чтобы установить composer на Windows , перейдите по ссылке https://getcomposer.org/doc/00-intro.md#installation-windows и скачайте инсталятор. Если во время установки у вас будут выскакивать ошибки библиотек, то просто зайдите в файл php.ini и отключите те библиотеки, которые не дают установится пакетному менеджеру composer .

После того, как composer установлен, перейдите на рабочий стол и создайте папку с названием "composer" . Теперь в консоли перейдите в нее

Cd Desktop/composer/

Чтобы инициализировать composer, введите команду

Composer init

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

Продолжим устанавливать наш фреймворк. Как я уже сказал, вводим

Search for a package:

Введите тут название нашего фреймворка

Search for a package: yii

Вы увидите перед собой все совпадения, которые нашел composer . Наш нужно yiisoft/yii Слева в квадратных скобках стоит номер. В моем случае это 0 , я ввожу его и нажимаю enter. Дальше нам нужно ввести версию. А откуда вообще composer все это качает? Есть такой сайт, где хранится много всякой всячины - http://packagist.org/ Там введите в строке поиска yii и перейдите по первой ссылке, там вы увидите, что версия называется dev-master . Введите это в консоль и нажмите enter.

Do you confine generation?

Выше этой надписи вы можете видеть, как выглядит файл composer.json . Это как раз таки тот файл, который вы дадите новому сотруднику.

Итак, нас все устраивает, нажимаем enter.

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

Теперь введите в консоль команду

Composer install

После того, как установка будет закончена, в нашей папке на рабочем столе появится новая папка с именем vendor , где хранятся все файлы нашего фреймворка.

Вот так легко работать с пакетным менеджером composer , а главное, что теперь вам не придется скачивать все вручную. Достаточно один раз сделать json файл и затем просто использовать его для скачки и установки нужных вам фреймворком, плагинов, библиотек и прочего.

Рекомендуем почитать