Когда я первый раз разбирался с composer, я набросал для себя маленькую шпаргалку и теперь, спустя некоторое время представляю её на суд общественности в несколько доработанном виде.
Данная публикация актуальная для тех, кто в первый раз столкнулся с незаменимым менеджером пакетов для PHP.
Итак, Composer — менеджер пакетов для PHP.
Для чего нужен Composer и простейший пример его использования
Возьмем для примера этот проект
Если в двух словах: то это набор скриптов для работы в VK API
Соответственно, для работы этих скриптов нужно несколько библиотек
Библиотеки перечислены в файле composer.json — ключевой файл при работе с composer
В этом проекте используется 5 библиотек. Соответственно, если разработчик решит опубликовать этот проект на github, то ему достаточно закинуть в репу саму папку со скриптами и составить composer.json, в котором будут описаны библиотеки, необходимые для работы этого проекта. Простота очевидна: в репу не нужно вслед за файлами прицепом тащить все нужные библиотеки. Занимает меньше места, проще распространять проект.
1. Что такое Composer, что у него внутри?
В папке scripts лежат непосредственно скрипты проекта, для работы которых и требуются эти 5 пакетов.
Запускаем установку пакетов:
После установки появляется папка vendor, куда складываются установленные пакеты и формируется файл autoload.php
Этот файл подключаем к проекту и всё — библиотеки подключены, можно спокойно с ними работать.
Простота очевидна: не нужно скачивать и подключать библиотеки и их зависимости самостоятельно, composer всё сделает за Вас. И вся эта пачка подключается одним единственным файлом autoload.php
Все пакеты, которые лежат в vendor, добавляются в автозагрузчик. При этом composer опирается на файлы composer.json, которые должны быть у каждого пакета. Формирование composer.json пакета — это задача разработчика пакета, от потребителя пакета требуется лишь описать в composer.json проекта, какие пакеты нужно подключить.
Это пример composer.json проекта:
Это пример composer.json пакета:
В секции require прописана зависимость этого пакета — библиотека guzzle http, необходимая для работы библиотеки getjump/vk. В данном случае, т.е. с точки зрения потребителя пакетов, всевозможные зависимости пакетов — это не наша «забота», с зависимостями composer разберётся сам.
Пространство имён пакета прописано в секции autoload
getjump\Vk\ — наименование пространства имён
src/getjump/Vk/ — директория, в которой лежат файлы с классами пакета
Работа с этой библиотекой в проекте:
Core и Friends — это классы библиотеки, которые разложены и прописаны в папке src в соответствии со стандартом PSR-4. Опять же формирование структуры пакета — это работа создателя пакета.
Нам, как потребителю пакета, достаточно прописать в наш проект
include ‘../vendor/autoload.php’;
и все эти классы и пространства имён будут отлично работать.
Composer php — пакетный менеджер
При этом нам не нужно заморачиваться и писать автозагрузчик. Composer это сделает сам при выполнении команды install.
Установка
Установка Composer глобально
1) Для начала нужно что бы путь к директории с интерпретатором PHP был прописан в переменной окружения path.
Проверим, так ли это:
php –version
Если вывод получился типа такого, то этот шаг можно пропустить
На примере Windows 7
Система -> Дополнительные параметры системы -> Дополнительно -> Переменные среды
Далее нас будет интересовать переменная path:
Вписываем путь к интерпретатору
*С давних времён у меня на компьютере лежит сборка xampp, сама сборка здесь нафиг не нужна, а вот интерпретатор с неё вполне подойдёт (версия PHP – 5.6).
2) Перезапускаем терминал.
Создаём директорию и ставим composer (я ставил на диск D)
D:
cd /
mkdir bin
cd bin
php -r «readfile(‘https://getcomposer.org/installer’);» | php
echo php «%~dp0composer.phar» %*>composer.bat
3) Добавим в переменную окружения path путь к composer.bat, например для D:bin должно получиться:
Дополнительно можно добавить в path
D:Users%userName%AppDataRoamingComposervendorbin
для того, что-бы было удобнее использовать инструменты, глобально установленные через Composer.
(У меня папка Users располагается на диске D, а на C создан симлинк на неё).
Всё, composer установлен и полностью готов к работе.
Ещё: при установке можно словить ошибку
[RuntimeException]
The APPDATA or COMPOSER_HOME environment variable must be set for composer to run correctly
Решение нашлось здесь github.com/composer/composer/issues/2033
Добавляем переменную APPDATA со значением D:UsersGSUAppDataRoaming
Установка Composer локально
Есть вариант ещё поставить composer локально, но в большинстве случаев в этом нет явной необходимости.
Однако тут установка ещё проще.
Т.к. программа глобально не установлена, нужен загрузочный файл(мини-программа composer), для его загрузки пишем команду:
php -r «readfile(‘https://getcomposer.org/installer’);» | php
теперь в директории проекта появился файл composer.phar
Всё, можно использовать.
php composer.phar require [название пакета]
Отличия глобальной и локальной установки
Команды запускаются по разному при локальной и глобальной установках:
Например:
Локально: php composer.phar require silex/silex ~1.1
Глобально: composer require silex/silex ~1.1
При локальной установке нужно каждый раз скачивать установочный файл в папку текущего проекта
php -r «readfile(‘https://getcomposer.org/installer’);» | php
При глобальной установке этот файл не нужен. Composer запускается при любой текущей директории.
Команды
install — установка пакетов, прописанных в composer.json
update – обновление пакетов
dumpautoload — пересборка автозагрузчика
require somepackage/somepackage:someversion — добавление нового пакета (по умолчанию пакеты ставятся из оф. репозитория). При установке пакет прописывается в composer.json
update —lock — обновление файла блокировки composer.lock
config —global cache-files-maxsize «2048MiB» — пример изменения параметра конфигурации
—profile — добавление этого параметра к любой команде включит показ времени выполнения и объёма использованной памяти
—verbose — подробная инфомация о выполняемой операции
show —installed — список установленных пакетов с описанием каждого
show —platform — сведения о PHP
—dry-run — репетиция выполнения команды. Может добавляться к командам install и update. Эмулирует выполнение команды без её непосредственного выполнения. Необходим для того, чтобы проверить пройдёт ли установка пакетов и зависимостей успешно.
remove — удаление пакета. Точная противоположность require
Синтаксис composer.json
Именование пакетов и варианты описания пакетов
Имя пакета состоит из двух частей разделёных косой чертой: названия поставщика (vendor name) и названия библиотеки.
Если пакет оформлен в соответствии со стандартом PSR-4, но опубликован не на packagist.org, а на github, то вместо версии пакета нужно прописать ветку и репозиторий для этого пакета:
Пример подключения библиотеки, которая лежит на github, но при этом не оформлена по стандарту PSR-4, а представляет из себя обыкновенное нагромождение файлов с классами и функциями.
Pqr/superlib — эта та самая «неправильная» библиотека.
В секции repositories для неё пишем такую конструкцию
Ключевой момент — секция autoload, здесь указываем нужные нам файлы с классами и функциями.
Структура библиотеки:
Соответственно в проекте вызов getCurrentTime() будет выглядеть примерно так:
$timer = new pqrsuperlibTimerClass;
echo $timer->getCurrentTime();
Версионирование
При указании допустимых версий пакетов можно использовать точное соответствие (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.5, 1.2.8 и тд.
Указание знака вставки (^1.2.3) буквально означает “опасаться только критических изменений” и будет включать в себя версии вплоть до 2.0. Применительно к семантическому версионированию, изменение мажорной версии является моментом внесения в проект критических изменений, так что версии 1.3, 1.4 и 1.9 подходят, в то время как 2.0 — уже нет.
Т.е. не меняется только первая цифра.
Тильда: ~1.2.3 — это самый распространённый и безопасный способ указания версии.
Файл composer.lock
Файл composer.lock сохраняет текущий список установленных зависимостей и их версии. Таким образом, на момент, когда версии зависимостей уже будут обновлены (команда update), другие люди, которые будут клонировать ваш проект, получат те же самые версии. Это позволяет убедиться в том, что каждый, кто получает ваш проект, имеет пакетное окружение, идентичное тому, которое вы использовали при разработке, и помогает избежать ошибок, которые могли бы возникнуть из-за обновления версий.
При каждом выполнении команды update версии обновлённый пакетов прописываются в composer.lock. Этот файл загоняется под систему контроля версий и при установке пакетов на новом сервере поставятся именно те версии пакетов, которые прописаны в этом файле. При выполнении команды install composer будет в первую очередь опираться на composer.lock. Таким образом на разных серверах будет гарантированно установлено одинаковое пакетное окружение с точки зрения версий.
Также, файл composer.lock содержит хэш файла composer.json.
И если json файл был отредактирован, то composer выдаст предупреждение, что файл lock не соответствует json файлу.
В таком случае, нужно выполнить команду composer update —lock, которая обновит composer.lock.
Отличие install от update в контексте использования composer.lock
Команда composer install делает следующее:
Проверяет существует ли composer.lock:
— если нет, резолвит зависимости и создаёт его
— если composer.lock существует, устанавливает версии, указанные в нём
Команда composer update:
— Проверяет composer.json
— Определяет последние версии на основе указанных в этом файле
— Устанавливает последние версии
— Обновляет composer.lock в соответствии с установленными
Пример использования с точки зрения создателя проекта
Имеется проект без установленных пакетов
Поставили несколько библиотек
У нас сформировался composer.json с информацией о пакетах
doctor Brain
Обычно, функционально завершенный блок кода формирует метод, группа методов объединяется в составе определенного класса, набор классов составляет пакет.
Повторно используемые пакеты, в свою очередь, являются частью различных проектов, и не подвергаются, при этом, модификации. Такие пакеты позовляют решать строго опредленные задачи, обеспечивая взаимодействие с клиентом через API.
Использование пакетов способствует соблюдению современных принципов разработки программного обеспечения, например, DRY: “Don’t Repeat Yourself”, значительно уменьшая количество дублирующейся информации всех видов.
В большинстве случаев, у пакетов есть зависимости. Когда для работы “Пакета A” требуется “Пакет B”, мы говорим, что “Пакет A” зависит от “Пакета B”. Довольно часто для пакета формируется цепь таких зависимостей (“Пакет A” зависит от “Пакета B”, “Пакет B” зависит от “Пакета C”, список можно продолжить).
Представьте, что пакетных менеджеров не существует. Какие действия необходимо осуществить, для того чтобы обеспечить работоспособность “Пакета A”, зависящего от “Пакета B”? Для начала мы скачаем исходный код “Пакета A”, после чего обнаружим, что его функциональность зависит от “Пакета B”. Поэтому мы приложим максимум усилий, для того чтобы найти исходный код “Пакета B”.
Но такой алгоритм может и не сработать, потому что мы не уверены, что в результате скачивания получим нужную версию “Пакета B”. Эту историю можно продолжить, а она касается только одной зависимости. Представляете, каким кошмаром обернется наличие у необходимого пакета множественных зависимостей или их цепочки.
Именно поэтому появилась необходимость в пакетном менеджере — инструменте, готовом взять на себя всю головную боль, связанную с поиском зависимых пакетов.
Composer vs. PEAR
PEAR
Кое-что с названием PEAR было еще до появляения Composer. Разработчики PHP с многолетним стажем наверняка знакомы с PEAR. Этот продукт сущестует с 1999 года.
PEAR, как и Composer, был создан с целью развития инфраструктуры повторного использования пакетов. Тем не менее, по ряду причин он был отвергнут сообществом разработчиков:
- в отличии от Composer, PEAR — системный пакетный менеджер. В таком случае, имея несколько проектов с пакетами различных версий, использующими одинаковые зависимости, разработчики получали множество проблем,
- для того, чтобы пакет был размещен в репозитарии PEAR, требовалось собрать определенное количество голосов. Это условие воспринималось негативно и не способствовало росту репозитария. В конце концов, программист должен писать код, а не заниматься его популяризацией.
Composer
Composer — это пакетный менеджер уровня приложений для PHP. Его создатель вдохновился примерами NodeJS NPM и Ruby’s Bundler. В настоящее время этот пакетный менеджер признан всем сообществом PHP-разработчиков.
Экосистема Composer содержит две части:
- собственно Composer, который является утилитой командной строки для установки пакетов,
- Packagist — репозитарий пакетов.
Пакетный менеджер уровня приложений управляет зависимостями только в пределах проекта. Это значительно облегчает управление проектами и предохраняет рабочее место от хранения большого количества ненужных файлов. Все необходимые пакеты хранятся в директории конкретного проекта.
Каждый разработчик может выкладывать свои пакеты в Packagist. В отличие от PEAR, нет необходимости набирать какие-то голоса. Тем не менее, популярность вашего проекта определяется собранными звездами.
Packagist
Как было написано выше, Packagist — дефолтный репозитарий пакетов для Composer. На момент написания этот статьи (ноябрь 2019) 244385 пакетов доступны для установки из этого репозитария. Каждый раз, перед тем как приступить к созданию с нуля какого-либо функционала на PHP, рекомендуется заглянуть в Packagist — скорее всего необходимая задача уже решена и пакет присутствует в репозитарии. Можно с уверенность сказать, что PHP-разработчики, использующие в своей работе Composer и Packagist, экономят кучу сил и времени.
Установка Composer
Существуют два варианта установки Composer: локальный и глобальный. Исходя из профессионального опыта, мы рекомедуем выбрать глобальную установку: скорее всего Вы будете использовать Composer для управления зависимостями во всех своих PHP-проектах. Глобальная установка избавляет от большого количества ненужных хлопот в перспективе.
Composer предлагает удобный установщик, который запускается из командной строки, актуальную версию можно взять здесь (в связи с тем, что инсталяционный код меняется по мере выхода новых версий продукта, нет смысла выкладывать его в этой статье).
MacOS/Linux/Unix
Для установки Composer требуется PHP версии 5.3.2+. Так же необходимо привести в соответствие некоторые настройки PHP, но нет смысла останавливаться на этом — установщик продукта предупредит о всех несовместимых параметрах. После успешной проверки настроек установщик скачает файл composer.phar в рабочую директорию.
PHAR — бинарный файл, формат архива для PHP, запускаемого из командной строки
Для глобальной установки composer.phar должен находиться в PATH . Поэтому сразу после удачного завершения работы установщика, необходимо выполнить следующую команду:
mv composer.phar /usr/local/bin/composer
Теперь для запуска пакетного менеджера достаточно набрать в консоли composer вместо php composer.phar .
Windows
Достаточно скачать и запустить установщик для Windows.
Актуальную информацию о глобальном и локальном вариантах установке Composer в различных операционных системах можно узнать здесь.
Проверка установки
Для того чтобы убедиться в том, что Composer установлен корректно, достаточно выполнить следующую команду (из директории установки — в случае локальной установки, из любой директории — в случае глобальной установки):
composer about
Если результат будет подобен этому, установка выполнена верно:
Composer — Dependency Manager for PHP Composer is a dependency manager tracking local dependencies of your projects and libraries. See https://getcomposer.org/ for more information.
Работа с Composer
Теперь Composer готов к работе. Рассмотрим небольшой пример:
Допустим, мы завершили работу над проектом, но для демонстрации его возможностей клиенту нужно сгенерировать пул даных: имена и адреса пользователей. Конечно, есть желание, чтобы такие данные выбирались случайным образом и, вообще, были максимально похожи на реальные.
Одно из решений: самостоятельно создать массив имен и адресов, а затем случайным образом выбирать из него значения с помощью функции array_rand(). Надеюсь, Вы понимаете, что это непрактичное и скучное решение. А что делать, если нам понадобятся сотни пользовательских данных? Нужно найти альтернативное решение.
На помощь приходит Packagist — здесь есть пакет, который справится с поставленной задачей на сто процентов. Он даже называется Faker.
Давайте установим Faker с помощью Composer.
Из корневой директории проекта выполним команду:
composer require fzaninotto/faker
Для установки пакета потребуется всего лишь несколько секунд. За это время Composer скачает zip-архив Faker с GitHub и создаст несколько внутренних файлов и папок.
После установки пакета в директории проекта можно обнаружить новые папки и файлы:
- composer.json
- composer.lock
- vendor
composer.json
Этот файл описывает зависимости в проекте. Это просто JSON-файл, демонстрирующий установленные для данного проекта пакеты.
Когда Вы запускаете из консоли команду composer require , файлы composer.json и composer.lock автоматически обновляются в соответствии с изменениями в составе пакетов. И наоборот, если пакеты добавлены в файл composer.json , достаточно из директории проекта выполнить команду composer install , для того, чтобы скачать необходимые пакеты. Если нужно обновить версии всех пакетов в проекте до последних, соответствующих установленным ограничениям, необходимо выполнить команду composer update .
Рассмотрим три основные команды Composer:
composer require
Команда добавляет к зависимостям строго определенный пакет. Когда к проекту нужно добавить один пакет, достаточно аыполнить команду composer require . Это очень удобно, так как нет необходимости лишний раз модифицировать файл composer.json .
Другое предназначение этой команды — обновление версий уже установленных пакетов. Например, в проекте установлена последняя версия пакета Faker (1.8.0) с помощью команды:
composer require fzaninotto/faker
В случае, когда при выполнении команды composer require не указана необходимая версия пакета, происходит скачивание последней доступной версии.
Допустим, тестируемое приложение несовместимо с пакетом версии 1.8.0, но отлично работает с более ранней версией — 1.4.0. Для того, чтобы решить возникшую проблему достаточно выполнить команду:
composer require fzaninotto/faker:1.4.0
В этом случае произойдет не только скачивание пакета установленной версии, но и корректное обновление соответствующих файлов Composer.
composer install
Эта команда в первую очередь обращается к файлу composer.lock . Если данный файл присутствует, для указанных в нем пакетов будут установлены версии в строгом соответствии с версиями определенными в composer.lock , следует заметить, что для этих пакетов содержимое файла composer.json будет проигнорировано. Если файл composer.lock отсутствует, команда обратится к composer.json и установит последние версии пакетов в соответствии с ограничениями определенными в этом файле.
Возникает вопрос: в чем различия?
Когда используется composer.lock , происходит установка строго определенной версии пакета. Когда идет обращение к composer.json Composer всегда пытается скачать наиболее свежую версию, в соответствии с ограниченями определенными в файле. Когда версия пакета должна определятся через точное соответствие, эти методы ничем не отличаются друг от друга. Но абсолютное соответствие версий требуется крайне редко.
Эта команда обычно используется в 3 случаях:
- при старте нового проекта, когда в файле определены все зависимости и нужно скачать необходимые пакеты,
- когда идет размещение проекта из внешего репозитария (например, с GitHub), пакеты не хранятся в проекте, команда запускается, чтобы установить необходимые пакеты, в соответствии с настройками файлов Composer,
- в некоторых стратегиях переноса проекта из разработки в “боевую” среду.
composer update
Эта команда отличается от composer install тем, что обращается только к файлу composer.json . Таким образом, команда обновляет только пакеты, определенные в этом файле до последних версий в соответствии с установленными в composer.json ограничениями. Так же composer update устанавливает все новые пакеты, добавленные в composer.json .
Таким образом, composer update , как и composer require можно использовать для того, чтобы актуализировать версии пакетов. Но composer require не трубует внесения предварительных изменений в composer.json .
Команда composer update обращается только к информации в файле composer.json — это создает логическую ловушку при переносе проекта в “боевую” среду.
composer update никогда нельзя использовать на продакшене
Ваше приложение успешно работает с пакетом Faker 1.4.0 в тестовой среде. Вы переносите проект в “боевые” условия и для установки пакетов запускаете composer update . Допустим, в файле composer.json определено нестрогое соответствие версии пакета Faker и имеет вид fzaninotto/faker: 1.* . Как результ, на продакшене окажется пакет Faker 1.8.0, несовместимый с данным приложением. То есть пакеты, в тестовой и боевой средах не будут идентичными. А это не тот результат, к которому мы стремимся.
Как избежать такой ситуации? Рекомендации просты:
- переносите composer.lock вместе с composer.json ,
- в “боевой” среде используйте только composer install
Соблюдение этих нехитрых условий позволит вам быть уверенными в полном соответствии переносимых пакетов.
composer.lock
В то время, как composer.json определяет состав пакетов, необходимых для проекта, и накладывает ограничения на используемые версии пакетов, composer.lock определяет точные версии пакетов, установленных в проекте. Иными словами composer.lock сохраняет текущее состояние проекта. Это очень важный момент, который необходимо знать.
Тот факт, что composer install сначала обращается к composer.lock , делает эту команду безопасной и приоритетной для использования. И вот почему:
Рассмотрим следующую ситуацию. Случайно из проекта удалили папку vendor со всеми установленными пакетами. Что делать? Достаточно запустить команду composer install и будут установлены все необходимые версии пакетов, используемых в проекте.
Но есть и другой вопрос. Если мы используем систему контроля версий (например, git), нужно ли хранить в репозитарии файл composer.lock ?
Это зависит от весьма простых условий:
- Обычно работа над проектом ведется в команде, и хочется быть уверенным в постоянной полной идентичности исходного кода в определенных ветках репозитария. Это означает, что composer.lock нужно коммитить и хранить в репозитарии.
- Когда идет работа над собственным пакетом или библиотекой, редко возникает необходимость в использовании команды composer install , в таком случае нет никакой необходимости в хранении в репозитарии файла composer lock .
Composer дает определенные свободы в использовании своих команд. Но существует несколько правил, которые лучше соблюдать, чтобы избежать неприятные ситуации:
- Зависимости определены в файле composer.json — используйте composer install .
- Есть необходимость в определенном пакете — используйте composer require some/package .
- Нужно установить несколько пакетов — определите их в composer.json и запустите composer update .
- Хотите протестировать новую версию определенного пакета — используйте composer rerquire some/package:new-version .
- Хотите протетсировать все новые версии установленных пакетов — используйте composer update .
Автозагрузка
Скорее всего Вы часто используете выражения include и require . Проблема в том, что такой подход делает код перегруженным. В наихудшем случае, изменение структуры проекта, влечет большой объем работы, связанной с поиском и заменой.
Решение — автозагрузка. Это решение позволяет определить пути для поиска классов и избавить разработчика от рутинной работы, связанной с подключением файлов через include и require . Конечно, мы должны помнить, что на самом деле автозагрузка использует все те же управляющие конструкции include и require .
Но, давайте еще раз вернемся к нашему вымышленному проекту. Остался еще один вопрос, которого мы не коснулись. А именно, директория vendor , которую создает Composer. По умолчанию Composer сохраняет все пакеты именно в этой директории.
Кроме того Composer создает файл vendor/autoload.php , который обеспечивает автозагрузку кода установленных пакетов.
В нашем случае, для использования возможностей пакета Fake, достаточно просто подключить автозагрузчик:
require __DIR__ . ‘/vendor/autoload.php’;
после этого Faker готов к работе:
$faker = FakerFactory::create(); echo $faker->name;
Сообщество
Итак, Вы получили достатчные знания о менеджере зависимостей Composer. Приступайте к его использованию в своих проектах. Можно гарантировать, что это значительно облегчит Вашу работу, как личную, так и в составе команды. Не забывайте обращаться к Packagist, перед тем как приступить к созданию собственного функционала.
Используйте все возможности сообщества.
Спасибо за внимание.
Новые публикации
JavaScript: сохраняем страницу в pdf
2021-07-12
HTML: Полезные примеры
2021-07-11
CSS: Ускоряем загрузку страницы
2021-07-10
JavaScript: 5 странностей
2021-07-10
JavaScript: конструктор сортировщиков
Категории
О нас
Frontend https://drbrain.ru/articles/modern-php-developer-composer/» target=»_blank»]drbrain.ru[/mask_link]
Установка и использование Composer в Ubuntu 18.04
Composer — это популярный менеджер зависимостей PHP, который упрощает процесс установки и обновления зависимостей проекта. Он проверяет, от каких прочих пакетов зависит конкретный проект, а затем устанавливает все необходимые версии пакетов в соответствии с требованиями.
Данное руководство поможет установить и начать работу с Composer на сервере Ubuntu 16.04.
Предварительные требования
Для данного обучающего руководства вам потребуется следующее:
- Один сервер Ubuntu 18.04, настроенный в соответствии с руководством по начальной настройке сервера Ubuntu 18.04, включая пользователя sudo без прав root и брандмауэр.
Шаг 1 — Установка зависимостей
Прежде чем приступить к загрузке и установке Composer, нужно убедиться, что на сервере установлены все зависимости.
Во-первых, необходимо обновить кэш менеджера пакетов:
Теперь мы установим зависимости. Нам потребуется curl , чтобы загрузить Composer, и php-cli для установки и запуска. Пакет php-mbstring необходим для предоставления функций для библиотеки, которую мы будем использовать. git используется Composer для загрузки зависимостей проекта, а unzip для извлечения заархивированных пакетов. Все пакеты можно установить при помощи следующей команды:
После установки всех обязательных пакетов мы можем переходить к установке Composer.
Шаг 2 — Загрузка и установка Composer
Composer предоставляет написанный на PHP установщик. Мы должны загрузить его, убедиться, что он не поврежден, а затем использовать его для установки Composer.
Убедитесь, что вы находитесь в домашней директории, а затем загрузите установщик с помощью curl :
Затем убедитесь, что хэш установщика совпадает с хэшем SHA-384 для последней версии установщика на странице Composer Public Keys / Signatures. Скопируйте хэш с этой страницы и сохраните его в качестве переменной командной строки:
-
HASH=544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdfdd586475ca9813a858088ffbc1f233e9b180f061
Обязательно замените последний хэш на выделенное красным значение.
Теперь выполните следующий PHP скрипт, чтобы убедиться, что скрипт установки безопасен для запуска:
Вы должны увидеть следующий вывод:
Installer verified
Если вы увидите Installer corrupt , вам нужно снова загрузить скрипт установки и повторно убедиться, что вы используете правильный хэш. Запустите команду и снова проверьте установщик. После успешной проверки установщика вы можете продолжить.
Чтобы выполнить глобальную установку composer , используйте следующую команду, которая выполнит загрузку и установку Composer в качестве общесистемной команды composer в каталоге /usr/local/bin :
Вывод должен выглядеть так:
OutputAll settings correct for using Composer Downloading. Composer (version 1.6.5) successfully installed to: /usr/local/bin/composer Use it: php /usr/local/bin/composer
Чтобы протестировать установку, запустите команду:
Вы должны получить подобный вывод с версией и аргументами Composer.
Output ______ / ____/___ ____ ___ ____ ____ ________ _____ / / / __ / __ `__ / __ / __ / ___/ _ / ___/ / /___/ /_/ / / / / / / /_/ / /_/ (__ ) __/ / ____/____/_/ /_/ /_/ .___/____/____/___/_/ /_/ Composer version 1.6.5 2018-05-04 11:44:59 Usage: command [options] [arguments] Options: -h, —help Display this help message -q, —quiet Do not output any message -V, —version Display this application version —ansi Force ANSI output —no-ansi Disable ANSI output -n, —no-interaction Do not ask any interactive question —profile Display timing and memory usage information —no-plugins Whether to disable plugins. -d, —working-dir=WORKING-DIR If specified, use the given directory as working directory. -v|vv|vvv, —verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug . . .
Это значит, что менеджер зависимостей Composer был успешно установлен и доступен в рамках всей системы.
Примечание: если вы предпочитаете иметь отдельные исполняемые модули Composer для каждого проекта, который вы размещаете на этом сервере, вы можете выполнить установку локально для каждого проекта. Пользователи NPM должны быть знакомы с данным подходом. Этот метод также полезен, когда системный пользователь не имеет прав на установку программного обеспечения в рамках всей системы.
Для этого воспользуйтесь командой php composer-setup.php . В результате будет сгенерирован файл composer.phar в текущей директории, который можно исполнить с помощью команды ./composer.phar .
А теперь давайте рассмотрим использование Composer для управления
Шаг 3 — Использование Composer в PHP проекте
PHP проекты часто зависят от внешних библиотек, и управление этими зависимостями и их версиями может вызывать затруднения. Composer решает эту проблему, отслеживая ваши зависимости и упрощая для других установку этих зависимостей.
Чтобы использовать Composer в вашем проекте, вам потребуется файл composer.json . Файл composer.json указывает Composer, какие зависимости для вашего проекта нужно загрузить, а также какие версии каждого пакета можно использовать. Это очень важно для сохранения последовательности вашего проекта и отказа от установки нестабильных версий, которые могут вызывать проблемы с обратной совместимостью.
Вам не нужно создавать этот файл вручную, потому что вы можете легко допустить ошибку в синтаксисе. Composer автоматически генерирует файл composer.json , когда вы добавляете в ваш проект зависимость с помощью команды require . Вы можете добавлять дополнительные зависимости таким же образом без необходимости вручную изменять файл.
Использование Composer для установки пакета в качестве зависимости в проект подразумевает следующие шаги:
- Определите, какая библиотека необходима приложению.
- Изучите подходящую библиотеку из открытого источника на Packagist.org, официальном репозитории пакетов для Composer.
- Выберите пакет, который вы будете использовать в качестве зависимости.
- Запустите composer require , чтобы включить зависимость в файл composer.json и установить пакет.
Давайте попробуем сделать это на примере демо-приложения.
Приложение преобразует указанное предложение в понятную человеку часть URL-адреса (slug). Как правило, подобные приложения используются для преобразования названия страницы в URL-адрес (например, последняя часть URL для данного обучающего руководства).
Начнем с создания директории для нашего проекта. Мы назовем его slugify.
Теперь нужно найти на Packagist.org пакет, который поможет нам генерировать понятные человеку части URL-адреса. При поиске термина «slug» на Packagist вы получите примерно такой результат:
Вы увидите два числа с правой стороны каждого пакета в списке. Число сверху указывает на количество установок пакета, а число внизу показывает, какие оценки пакету ставили на GitHub. Вы можете изменить порядок результатов поиска на основе этих чисел (посмотрите на два значка с правой стороны панели поиска). Как правило, пакеты с большим количеством установок и большим количеством звезд более стабильны, потому что многие люди их используют. Также важно проверить описание пакета на соответствие тому, что вам нужно.
Нам нужен простой конвертер из строки в понятную человеку часть URL-адреса. Судя по результатам поиска пакет cocur/slugify кажется наиболее подходящим вариантом с большим количеством установок и звезд (Пакет расположен ниже в результатах поиска, чем видно на скриншоте).
Пакеты на Packagist имеют имя автора и имя пакета. Каждый пакет имеет уникальный идентификатор (пространство имен) в том же формате, который использует GitHub для своих репозиториев в форме автор/пакет . Библиотека, которую мы хотим установить, использует пространство имен cocur/slugif . Вам нужно пространство имен, чтобы использовать пакет в вашем проекте.
Теперь, когда вы знаете, какой пакет хотите установить, запустите composer require , чтобы использовать его в качестве зависимости, а также сгенерировать файл composer.json для проекта:
Вы увидите следующий вывод, когда Composer загрузит зависимость:
OutputUsing version ^3.1 for cocur/slugify ./composer.json has been created Loading composer repositories with package information Updating dependencies (including require-dev) Package operations: 1 install, 0 updates, 0 removals — Installing cocur/slugify (v3.1): Downloading (100%) Writing lock file Generating autoload files
Как видите, Composer автоматически определил, какую версию пакета использовать. Если вы сейчас проверите каталог вашего проекта, он будет содержать два новых файла: composer.json и composer.lock , а также каталог vendor .
Outputtotal 12 -rw-rw-r— 1 sammy sammy 59 Jul 11 16:40 composer.json -rw-rw-r— 1 sammy sammy 2934 Jul 11 16:40 composer.lock drwxrwxr-x 4 sammy sammy 4096 Jul 11 16:40 vendor
Файл composer.lock используется для хранения информации о том, какие версии каждого пакета установлены, а также для использования одних и тех же версий пакетов, если кто-либо будет клонировать ваш проект и устанавливать зависимости. Каталог vendor служит местом расположения зависимостей проекта. Папка vendor не обязательно будет использоваться для контроля версий, вы должны поместить туда только файлы composer.json и composer.lock.
При установке проекта, который уже содержит файл composer.json , запустите composer install , чтобы загрузить зависимости проекта.
Давайте быстро пробежимся по ограничениям версии. Если вы просмотрите содержимое файла composer.json , то увидите следующее:
Output «require»: «cocur/slugify»: «^3.1» > > sam
Вы можете заметить специальный символ ^ перед номером версии в файле composer.json . Composer поддерживает несколько ограничений и форматов для определения требуемой версии пакета, чтобы обеспечить гибкость и одновременно сохранить стабильность вашего проекта. Оператор карет ( ^ ), используемый в автоматически генерируемом файле composer.json , рекомендуется применять для обеспечения максимальной совместимости в соответствии с семантическим управлением версиями. В данном случае он определяет 3.1 в качестве минимальной совместимой версии и позволяет обновляться до любой будущей версии ниже 4.0.
Как правило, вам не нужно изменять ограничения версии в файле composer.json . Однако в некоторых ситуациях может потребоваться вручную отредактировать ограничения для экземпляра, например, при выходе крупного обновления требуемой библиотеки, а также в случае, когда библиотека, которую вы хотите использовать, не соответствует требованиям семантического управления версиями.
Ниже представлены примеры, которые помогут лучше понять, как работают ограничения версии в Composer:
| ^1.0 | >= 1.0 < 2.0 | 1.0, 1.2.3, 1.9.9 |
| ^1.1.0 | >= 1.1.0 < 2.0 | 1.1.0, 1.5.6, 1.9.9 |
| ~1.0 | >= 1.0 < 2.0.0 | 1.0, 1.4.1, 1.9.9 |
| ~1.0.0 | >= 1.0.0 < 1.1 | 1.0.0, 1.0.4, 1.0.9 |
| 1.2.1 | 1.2.1 | 1.2.1 |
| 1.* | >= 1.0 < 2.0 | 1.0.0, 1.4.5, 1.9.9 |
| 1.2. * | >= 1.2 < 1.3 | 1.2.0, 1.2.3, 1.2.9 |
Более подробное описание ограничений версии в Composer см. в официальной документации.
Теперь нужно рассмотреть, как автоматически загружать зависимости с помощью Composer.
Шаг 4 — Включение скрипта автозагрузки
Поскольку PHP не загружает классы автоматически, Composer предоставляет скрипт автозагрузки, который можно включить в ваш проект, чтобы использовать автозагрузку бесплатно. Это значительно упрощает работу с зависимостями.
Вам нужно будет только включить файл vendor/autoload.php в скрипты PHP перед созданием экземпляра любого класса. Composer автоматически генерирует этот файл при добавлении первой зависимости.
Давайте попробуем сделать это в нашем приложении. Создайте файл test.php и откройте его в текстовом редакторе:
Добавьте следующий код, который будет подключать файл vendor/autoload.php , загружать зависимость cocur/slugify и использовать ее для создания понятной человеку части URL-адреса:
require __DIR__ . ‘/vendor/autoload.php’; use CocurSlugifySlugify; $slugify = new Slugify(); echo $slugify->slugify(‘Hello World, this is a long sentence and I need to make a slug from it!’);
Сохраните файл и закройте редактор.
Вы должны получить вывод hello-world-this-is-a-long-sentence-and-i-need-to-make-a-slug-from-it .
Зависимости нуждаются в обновлениях при выходе новых версий, так что давайте рассмотрим, как решить эту проблему.
Шаг 5 — Обновление зависимостей проекта
Если вам нужно обновить зависимости проекта на более поздние версии, запустите команду update :
Она будет проверять новые версии библиотек, которые требуются вам в вашем проекте. Если будет найдена новая версия, которая совместима с ограничением версии, определенным в файле composer.json , Composer заменит ранее установленную версию на новую. Файл composer.lock будет обновлен, чтобы отразить эти изменения.
Вы также можете обновить одну или несколько конкретных библиотек, указав их следующим образом:
Обязательно проверьте файлы composer.json и composer.lock после обновления зависимостей, чтобы другие тоже могли установить обновленные версии.
Заключение
Composer — это мощный инструмент, который должен быть в арсенале каждого разработчика PHP. В этом обучающем руководстве вы установили Composer и использовали его при создании простого проекта. Теперь вы умеете устанавливать и обновлять зависимости.
Помимо обеспечения удобного и надежного способа управления зависимостями проекта, этот инструмент задает новый стандарт для обмена и обнаружения пакетов PHP, созданных сообществом.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Источник: www.digitalocean.com