Предложите контейнер библиотеки, что это за программа в автозагрузке

Обновлено: 21.11.2024

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

В этом руководстве вы установите Composer и начнете работу с ним в системе Ubuntu 20.04.

Предпосылки

Чтобы следовать этому руководству, вам потребуется доступ к серверу Ubuntu 20.04 в качестве пользователя sudo без полномочий root и включенный брандмауэр на вашем сервере. Чтобы настроить это, вы можете следовать нашему руководству по первоначальной настройке сервера для Ubuntu 20.04.

Если вы предпочитаете следовать этому руководству, используя терминал в браузере, нажмите кнопку Запустить интерактивный терминал! кнопку, чтобы начать. Вы сможете поэкспериментировать и запустить все команды прямо в браузере.

Запустите интерактивный терминал!

Шаг 1 — Установка PHP и дополнительных зависимостей

Помимо зависимостей, которые уже должны быть включены в вашу систему Ubuntu 20.04, таких как git и curl , Composer требует php-cli для выполнения PHP-скриптов в командной строке и unzip для извлечения заархивированных архивов. Сейчас мы установим эти зависимости.

Сначала обновите кеш менеджера пакетов, выполнив:

Затем выполните следующую команду, чтобы установить необходимые пакеты:

Вам будет предложено подтвердить установку, набрав Y, а затем ENTER .

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

Шаг 2 — Загрузка и установка Composer

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

Убедитесь, что вы находитесь в своем домашнем каталоге, а затем получите установщик с помощью curl :

Далее мы проверим, соответствует ли загруженный установщик хэшу SHA-384 последней версии установщика, найденной на странице открытых ключей и подписей Composer. Чтобы облегчить этап проверки, вы можете использовать следующую команду для программного получения последнего хэша со страницы Composer и сохранения его в переменной оболочки:

Если вы хотите проверить полученное значение, вы можете запустить:

Теперь выполните следующий PHP-код, как показано на странице загрузки Composer, чтобы убедиться, что сценарий установки безопасен для запуска:

Вы увидите следующий вывод:

Если в выводе указано, что установщик поврежден , вам нужно снова загрузить сценарий установки и еще раз проверить, что вы используете правильный хэш. Затем повторите процесс проверки. Если у вас есть проверенный установщик, вы можете продолжить.

Чтобы установить композитор глобально, используйте следующую команду, которая загрузит и установит Composer как общесистемную команду с именем composer в /usr/local/bin :

Вы увидите вывод, похожий на этот:

Чтобы проверить установку, запустите:

Это подтверждает, что Composer был успешно установлен в вашей системе и доступен для всей системы.

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

Для этого используйте команду php /tmp/composer-setup.php. Это создаст файл composer.phar в вашем текущем каталоге, который можно запустить с помощью php composer.phar .

Теперь давайте рассмотрим использование Composer для управления зависимостями.

Шаг 3. Использование Composer в проекте PHP

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

Чтобы использовать Composer в своем проекте, вам понадобится файл composer.json. Файл composer.json сообщает Composer, какие зависимости необходимо загрузить для вашего проекта и какие версии каждого пакета разрешено устанавливать. Это чрезвычайно важно для обеспечения согласованности проекта и предотвращения установки нестабильных версий, которые потенциально могут вызвать проблемы с обратной совместимостью.

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

Процесс использования Composer для установки пакета в качестве зависимости в проекте включает следующие шаги:

Давайте попробуем это с демо-приложением.

Целью этого приложения является преобразование заданного предложения в строку, удобную для URL, — slug. Это обычно используется для преобразования заголовков страниц в URL-пути (например, в последней части URL-адреса для этого руководства).

Давайте начнем с создания каталога для нашего проекта. Мы назовем это slugify:

Хотя это и не требуется, теперь вы можете запустить команду composer init, чтобы создать подробный файл composer.json для вашего проекта. Поскольку единственная цель нашего проекта — продемонстрировать, как устанавливать зависимости с помощью Composer, мы будем использовать более простой файл composer.json, который будет сгенерирован автоматически, когда нам понадобится наш первый пакет.

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

Нам нужен преобразователь строки в ярлык. Судя по результатам поиска, пакет cocur/slugify , который отображается в качестве первого результата на этой странице, кажется подходящим, с разумным количеством установок и звездочек.

Пакеты в Packagist имеют имя поставщика и имя пакета. Каждый пакет имеет уникальный идентификатор (пространство имен) в том же формате, который GitHub использует для своих репозиториев: поставщик/пакет. Библиотека, которую мы хотим установить, использует пространство имен cocur/slugify. Вам нужно пространство имен пакета, чтобы оно требовалось в вашем проекте.

Теперь, когда вы точно знаете, какой пакет хотите установить, вы можете запустить composer require, чтобы включить его в качестве зависимости, а также создать файл composer.json для своего проекта. Одна вещь, которую важно отметить при запросе пакетов, заключается в том, что Composer отслеживает как зависимости уровня приложения, так и зависимости уровня системы. Зависимости системного уровня важны для указания того, какие модули PHP зависят от пакета. В случае с пакетом cocur/slugify требуется модуль PHP, который мы еще не установили.

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

Чтобы решить проблему зависимости системы, мы можем найти отсутствующий пакет с помощью apt search:

Найдя правильное имя пакета, вы можете снова использовать apt для установки системной зависимости:

После завершения установки вы можете снова запустить команду composer require:

Как видно из вывода, Composer автоматически решает, какую версию пакета использовать. Если вы сейчас проверите каталог вашего проекта, он будет содержать два новых файла: composer.json и composer.lock , а также каталог поставщика:

Файл composer.lock используется для хранения информации об установленных версиях каждого пакета, а также для обеспечения использования одних и тех же версий, если кто-то другой клонирует ваш проект и устанавливает его зависимости. В каталоге поставщика находятся зависимости проекта. Папку поставщика не следует передавать в систему управления версиями — вам нужно только включить файлы composer.json и composer.lock.

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

Давайте кратко рассмотрим ограничения версий. Если вы проверите содержимое вашего файла composer.json, вы увидите что-то вроде этого:

Вы могли заметить специальный символ ^ перед номером версии в composer.json. Composer поддерживает несколько различных ограничений и форматов для определения требуемой версии пакета, чтобы обеспечить гибкость, а также сохранить стабильность вашего проекта. Оператор вставки ( ^ ), используемый автоматически созданным файлом composer.json, является рекомендуемым оператором для максимальной совместимости после семантического управления версиями. В этом случае он определяет 4.0 как минимальную совместимую версию и разрешает обновления до любой будущей версии ниже 5.0.

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

Вот несколько примеров, которые помогут вам лучше понять, как работают ограничения версии Composer:

Давайте попробуем это в нашем демонстрационном приложении. Откройте новый файл с именем test.php в текстовом редакторе:

Добавьте следующий код, который загружает файл vendor/autoload.php, загружает зависимость cocur/slugify и использует ее для создания ярлыка:

Сохраните файл и выйдите из редактора.

Теперь запустите скрипт:

Это приводит к выводу: привет, мир, это длинное предложение, и мне нужно сделать из него слаг .

Зависимости нуждаются в обновлении при выходе новых версий, поэтому давайте посмотрим, как с этим справиться.

Шаг 5 — Обновление зависимостей проекта

Всякий раз, когда вы хотите обновить зависимости вашего проекта до более поздних версий, запустите команду обновления:

Это проверит наличие более новых версий библиотек, необходимых для вашего проекта. Если будет найдена более новая версия и она совместима с ограничением версии, определенным в файле composer.json, Composer заменит установленную предыдущую версию. Файл composer.lock будет обновлен, чтобы отразить эти изменения.

Вы также можете обновить одну или несколько конкретных библиотек, указав их следующим образом:

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

Заключение

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

Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean!

Присоединяйтесь к нашему сообществу DigitalOcean, насчитывающему более миллиона разработчиков, бесплатно! Получайте помощь и делитесь знаниями в нашем разделе "Вопросы и ответы", находите руководства и инструменты, которые помогут вам расти как разработчику и масштабировать свой проект или бизнес, а также подписывайтесь на интересующие вас темы.

Время от времени вам может понадобиться использовать сторонний код в ваших приложениях Yii. Или вы можете использовать Yii в качестве библиотеки в некоторых сторонних системах. В этом разделе мы покажем, как достичь этих целей.

Использование сторонних библиотек в Yii ¶

Чтобы использовать стороннюю библиотеку в приложении Yii, вам в первую очередь нужно убедиться, что классы в библиотеке правильно включены или могут загружаться автоматически.

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

Многие сторонние библиотеки выпускаются в виде пакетов Composer. Вы можете установить такие библиотеки, выполнив следующие два простых шага:

  1. измените файл composer.json вашего приложения и укажите, какие пакеты Composer вы хотите установить.
  2. запустите composer install, чтобы установить указанные пакеты.

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

Использование загруженных библиотек ¶

Если библиотека не выпущена в виде пакета Composer, для ее установки необходимо следовать инструкциям по установке. В большинстве случаев вам потребуется загрузить файл выпуска вручную и распаковать его в каталог BasePath/vendor, где BasePath представляет собой базовый путь вашего приложения.

Если библиотека содержит собственный автозагрузчик классов, вы можете установить его в сценарии входа вашего приложения. Рекомендуется выполнять установку до включения файла Yii.php, чтобы автозагрузчик классов Yii имел приоритет над классами автозагрузки.

Если в библиотеке нет автозагрузчика классов, но имена классов соответствуют PSR-4, вы можете использовать автозагрузчик классов Yii для автоматической загрузки классов. Все, что вам нужно сделать, это просто объявить корневой псевдоним для каждого корневого пространства имен, используемого в его классах. Например, предположим, что вы установили библиотеку в каталог vendor/foo/bar, а классы библиотеки находятся в корневом пространстве имен xyz. В конфигурацию приложения можно включить следующий код:

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

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

  • Определите, какие классы содержит библиотека.
  • Перечислите классы и соответствующие пути к файлам в Yii::$classMap в сценарии ввода приложения. Например,

Использование Yii в сторонних системах ¶

Поскольку Yii предоставляет множество отличных функций, иногда вам может понадобиться использовать некоторые из его функций для поддержки разработки или усовершенствования сторонних систем, таких как WordPress, Joomla или приложений, разработанных с использованием других фреймворков PHP. Например, вы можете использовать класс yii\helpers\ArrayHelper или функцию Active Record в сторонней системе. Для достижения этой цели вам в основном нужно сделать два шага: установить Yii и загрузить Yii.

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

Если вы хотите использовать только уровень абстракции базы данных или другие функции Yii, не связанные с активами, вам потребуется специальный пакет композитора, который предотвращает установку пакетов Bower и NPM. Подробнее см. в cebe/assetfree-yii2.

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

В противном случае вы можете загрузить файл выпуска Yii и распаковать его в каталог BasePath/vendor.

Далее вам следует изменить сценарий входа сторонней системы, включив в начало следующий код:

Как видите, приведенный выше код очень похож на сценарий входа типичного приложения Yii. Единственное отличие состоит в том, что после создания экземпляра приложения метод run() не вызывается. Это связано с тем, что при вызове run() Yii возьмет на себя управление рабочим процессом обработки запросов, который в данном случае не нужен и уже обрабатывается существующим приложением.

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

Теперь вы можете использовать большинство функций Yii. Например, вы можете создавать классы Active Record и использовать их для работы с базами данных.

Использование Yii 2 с Yii 1 ¶

Если вы ранее использовали Yii 1, скорее всего, у вас есть работающее приложение Yii 1. Вместо того, чтобы переписывать все приложение в Yii 2, вы можете просто улучшить его, используя некоторые функции, доступные только в Yii 2. Этого можно добиться, как описано ниже.

Примечание: для Yii 2 требуется PHP 5.4 или выше. Вы должны убедиться, что и ваш сервер, и существующее приложение поддерживают это.

Сначала установите Yii 2 в существующее приложение, следуя инструкциям, приведенным в последнем подразделе.

Во-вторых, измените сценарий входа приложения следующим образом:

Поскольку и Yii 1, и Yii 2 имеют класс Yii, вам следует создать специальную версию, чтобы объединить их. Приведенный выше код включает настроенный файл класса Yii, который можно создать следующим образом.

Вот и все! Теперь в любой части вашего кода вы можете использовать Yii::$app для доступа к экземпляру приложения Yii 2, а Yii::app() предоставит вам экземпляр приложения Yii 1:

По запросу «контейнер для внедрения зависимостей» на сайте packagegist в настоящее время выдается более 95 страниц результатов. Можно с уверенностью сказать, что это конкретное «колесо» было изобретено.

Однако ни один повар не научился готовить, используя только готовые блюда. Точно так же ни один разработчик никогда не изучал программирование, используя только «готовый код».

В этой статье мы узнаем, как создать простой пакет контейнера для внедрения зависимостей. Весь код, написанный в этой статье, а также аннотации PHPDoc и модульные тесты со 100% охватом доступны в этом репозитории GitHub. Он также указан на Packagist.

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

Давайте начнем с планирования того, что мы хотим, чтобы наш контейнер делал. Хорошим началом является разделение «Контейнера внедрения зависимостей» на две роли: «Внедрение зависимостей» и «Контейнер».

Двумя наиболее распространенными способами внедрения зависимостей являются внедрение конструктора или внедрение установщика. То есть передача зависимостей класса через аргументы конструктора или вызовы методов. Если наш контейнер сможет создавать экземпляры и содержать сервисы, он должен уметь делать и то, и другое.

Чтобы быть контейнером, он должен иметь возможность хранить и извлекать экземпляры служб. Это довольно тривиальная задача по сравнению с созданием сервисов, но она все же заслуживает некоторого внимания. Пакет container-interop предоставляет набор интерфейсов, которые могут реализовывать контейнеры. Первичный интерфейс — это ContainerInterface, который определяет два метода: один для получения службы и один для проверки того, определена ли служба.

Изучение других контейнеров внедрения зависимостей

Контейнер внедрения зависимостей Symfony позволяет нам определять сервисы различными способами. В YAML конфигурация контейнера может выглядеть следующим образом:

То, как Symfony разделяет конфигурацию контейнера на конфигурацию параметров и сервисов, очень полезно. Это позволяет хранить секреты приложений, такие как ключи API, ключи шифрования и токены аутентификации, в файлах параметров, которые исключены из репозиториев исходного кода.

В PHP такая же конфигурация для компонента Symfony Dependency Injection будет выглядеть так:

Используя объект Reference в вызове метода setMailer , логика внедрения зависимостей может определить, что это значение не должно передаваться напрямую, а заменено службой, на которую оно ссылается в контейнере. Это позволяет легко внедрить в службу как значения PHP, так и другие службы без путаницы.

Начало работы

Первое, что нужно сделать, это создать новый каталог проекта и создать файл composer.json, который Composer может использовать для автоматической загрузки наших классов. На данный момент все, что делает этот файл, — это сопоставляет пространство имен SitePoint\Container с каталогом src.

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

Наряду с основным ContainerInterface пакет container-interop также определяет два интерфейса исключений. Первый для общих исключений, возникших при создании службы, а другой — для случаев, когда запрошенная служба не может быть найдена. Мы также добавим в этот список еще одно исключение, когда запрошенный параметр не может быть найден.

Поскольку нам не нужно добавлять какие-либо функции помимо того, что предлагает базовый класс PHP Exception, эти классы довольно просты. Хотя они могут показаться бессмысленными, разделение их таким образом позволяет нам легко ловить и обрабатывать их независимо друг от друга.

Создайте каталог src и создайте эти три файла в src/Exception/ContainerException.php , src/Exception/ServiceNotFoundException.php и src/Exception/ParameterNotFoundException.php соответственно:

Ссылки на контейнер

Класс Symfony Reference, рассмотренный ранее, позволял библиотеке различать значения PHP, используемые напрямую, и аргументы, которые нужно было заменить другими службами в контейнере.

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

Создайте следующие файлы в src/Reference/AbstractReference.php , src/Reference/ServiceReference.php и src/Reference/ParameterReference.php соответственно:

Класс-контейнер

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

Общая идея состоит в том, чтобы принять два массива в конструкторе нашего контейнера. Первый массив будет содержать определения службы, а второй — определения параметров.

В src/Container.php поместите следующий код:

Все, что мы здесь делаем, — это реализуем ContainerInterface из container-interop и загружаем определения в свойства, к которым можно получить доступ позже. Мы также создали свойство serviceStore и инициализировали его пустым массивом. Когда контейнеру будет предложено создать службы, мы сохраним их в этом массиве, чтобы их можно было получить позже без необходимости их повторного создания.

Теперь давайте начнем писать методы, определенные в container-interop . Начиная с get($name) добавьте в класс следующий метод:

Обязательно добавьте оператор использования в начало файла. Наш метод get($name) просто проверяет, есть ли в контейнере определение сервиса. Если это не так, создается исключение ServiceNotFoundException, которое мы создали ранее. Если это так, он возвращает службу, создает ее и сохраняет в хранилище, если это еще не сделано.

Пока мы на этом, мы должны сделать метод для извлечения параметра из контейнера. Предполагая, что параметры, переданные конструктору, образуют N-мерный ассоциативный массив, нам нужен какой-то способ чистого доступа к любому элементу в этом массиве с использованием одной строки. Простой способ сделать это — использовать . в качестве разделителя, чтобы строка foo.bar ссылалась на ключ bar в ключе foo корневого массива параметров.

Теперь мы использовали пару методов, которые еще не написали. Первый из них — это метод has($name), который также определяется в container-interop. Это довольно простой метод, и ему просто нужно проверить, содержит ли массив определений, предоставленный конструктору, запись для службы $name.

Другой вызываемый нами метод, который нам еще предстоит написать, — это метод createService($name). Этот метод будет использовать определения, предоставленные для создания службы. Поскольку мы не хотим, чтобы этот метод вызывался из-за пределов контейнера, мы сделаем его приватным.

Первое, что нужно сделать в этом методе, — это проверить работоспособность. Для каждого определения службы нам требуется массив, содержащий ключ класса и необязательные аргументы и ключи вызовов. Они будут использоваться для внедрения конструктора и внедрения сеттера соответственно. Мы также можем добавить защиту от циклических ссылок, проверив, не пытались ли мы уже создать службу.

Если ключ arguments существует, мы хотим преобразовать этот массив определений аргументов в массив значений PHP, которые можно передать конструктору. Для этого нам потребуется преобразовать ссылочные объекты, которые мы определили ранее, в значения, на которые они ссылаются из контейнера. Сейчас мы применим эту логику в методе resolveArguments($name, array $argumentDefinitons). Мы используем метод ReflectionClass::newInstanceArgs() для создания службы с использованием массива аргументов. Это внедрение конструктора.

Если ключ вызовов существует, мы хотим использовать массив определений вызовов и применить их к только что созданной службе. Опять же, мы вынесем эту логику в отдельный метод, определенный как initializeService($service, $name, array $callDefinitions) . Это внедрение сеттера.

Поэтому у нас остается два последних метода для создания. Первый должен преобразовать массив определений аргументов в массив значений PHP. Для этого ему потребуется заменить объекты ParameterReference и ServiceReference соответствующими параметрами и службами из контейнера.

Последний метод выполняет инъекцию установщика для созданного объекта службы. Для этого ему нужно перебрать массив определений вызовов методов. Ключ метода используется для указания метода, а необязательный ключ аргументов может использоваться для предоставления аргументов для вызова этого метода. Мы можем повторно использовать только что написанный метод для перевода этих аргументов в значения PHP.

Теперь у нас есть полезный контейнер для внедрения зависимостей! Чтобы увидеть примеры использования, посетите репозиторий на GitHub.

Заключительные мысли

Мы научились создавать простой контейнер для внедрения зависимостей, но существует множество контейнеров с интересными функциями, которых у нас пока нет!

Некоторые контейнеры внедрения зависимостей, такие как PHP-DI и Aura.Di, предоставляют функцию, называемую автоподключением. Именно здесь контейнер угадывает, какие службы из контейнера следует внедрить в другие. Для этого они используют API отражения, чтобы узнать информацию о параметрах конструктора.

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

Вы также можете использовать комментарии ниже, чтобы связаться с нами. Сообщите нам обо всем, что вы хотели бы прояснить или объяснить, или о любых обнаруженных ошибках.

Следите за новостями о других подобных статьях на SitePoint PHP. Скоро мы объясним, как заново изобрести колесо с помощью ряда распространенных компонентов PHP!

Composer – это популярный инструмент управления зависимостями для PHP, созданный главным образом для облегчения установки и обновления зависимостей проекта. Он проверит, от каких других пакетов зависит конкретный проект, и установит их для вас, используя соответствующие версии в соответствии с требованиями проекта.

В этом руководстве вы установите Composer и начнете работу с ним в системе Ubuntu 18.04.

Предпосылки

Для выполнения этого руководства вам потребуется:

  • Один сервер Ubuntu 18.04, настроенный в соответствии с руководством по первоначальной настройке сервера Ubuntu 18.04, включая пользователя без полномочий root и брандмауэр.

Шаг 1 — Установка зависимостей

Перед загрузкой и установкой Composer убедитесь, что на вашем сервере установлены все зависимости.

Сначала обновите кеш менеджера пакетов, выполнив:

Теперь давайте установим зависимости. Нам понадобится curl для загрузки Composer и php-cli для его установки и запуска. Пакет php-mbstring необходим для предоставления функций для библиотеки, которую мы будем использовать. git используется Composer для загрузки зависимостей проекта и unzip для извлечения заархивированных пакетов. Все можно установить с помощью следующей команды:

Установив необходимые компоненты, мы можем установить сам Composer.

Шаг 2 — Загрузка и установка Composer

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

Убедитесь, что вы находитесь в своем домашнем каталоге, а затем получите установщик с помощью curl :

Затем убедитесь, что установщик соответствует хэшу SHA-384 последней версии установщика, найденной на странице "Открытые ключи/подписи Composer". Скопируйте хэш с этой страницы и сохраните его как переменную оболочки:

Убедитесь, что вы заменили выделенное значение последним хэшем.

Теперь выполните следующий PHP-скрипт, чтобы убедиться, что запуск установочного скрипта безопасен:

Вы увидите следующий вывод.

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

Чтобы установить композитор глобально, используйте следующую команду, которая загрузит и установит Composer как общесистемную команду с именем composer в /usr/local/bin :

Вы увидите следующий вывод:

Чтобы проверить установку, запустите:

И вы увидите этот вывод, отображающий версию и аргументы Composer.

Это подтверждает, что 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 для установки пакета в качестве зависимости в проекте включает следующие шаги:

Давайте попробуем это с демо-приложением.

Целью этого приложения является преобразование заданного предложения в строку, удобную для URL, — slug. Это обычно используется для преобразования заголовков страниц в URL-пути (например, в последней части URL-адреса для этого руководства).

Давайте начнем с создания каталога для нашего проекта. Мы назовем это slugify:

Вы увидите два числа справа от каждого пакета в списке. Число вверху показывает, сколько раз был установлен пакет, а число внизу показывает, сколько раз пакет был отмечен звездочкой на GitHub. Вы можете изменить порядок результатов поиска на основе этих номеров (ищите два значка в правой части строки поиска). Вообще говоря, пакеты с большим количеством установок и большим количеством звезд имеют тенденцию быть более стабильными, поскольку их использует очень много людей. Также важно проверить актуальность описания пакета, чтобы убедиться, что это то, что вам нужно.

Нам нужен простой преобразователь строки в slug. Судя по результатам поиска, пакет cocur/slugify кажется подходящим, с разумным количеством установок и звездочек. (Пакет находится немного ниже по странице, чем показано на снимке экрана.)

Пакеты в Packagist имеют имя поставщика и имя пакета. Каждый пакет имеет уникальный идентификатор (пространство имен) в том же формате, который GitHub использует для своих репозиториев, в форме поставщик/пакет. Библиотека, которую мы хотим установить, использует пространство имен cocur/slugif. Вам нужно пространство имен, чтобы требовать пакет в вашем проекте.

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

Вы увидите этот вывод, когда Composer загрузит зависимость:

Как видно из вывода, Composer автоматически решает, какую версию пакета использовать. Если вы сейчас проверите каталог вашего проекта, он будет содержать два новых файла: composer.json и composer.lock , а также каталог поставщика:

Файл composer.lock используется для хранения информации об установленных версиях каждого пакета, а также для обеспечения использования одних и тех же версий, если кто-то другой клонирует ваш проект и устанавливает его зависимости. В каталоге поставщика находятся зависимости проекта. Папку поставщика не нужно передавать в систему управления версиями — вам нужно только включить файлы composer.json и composer.lock.

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

Давайте кратко рассмотрим ограничения версий. Если вы проверите содержимое вашего файла composer.json, вы увидите что-то вроде этого:

Вы могли заметить специальный символ ^ перед номером версии в composer.json. Composer поддерживает несколько различных ограничений и форматов для определения требуемой версии пакета, чтобы обеспечить гибкость, а также сохранить стабильность вашего проекта. Оператор вставки ( ^ ), используемый автоматически созданным файлом composer.json, является рекомендуемым оператором для максимальной совместимости после семантического управления версиями. В этом случае он определяет 4.0 как минимальную совместимую версию и разрешает обновления до любой будущей версии ниже 5.0.

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

Вот несколько примеров, которые помогут вам лучше понять, как работают ограничения версии Composer:

Давайте попробуем это в нашем приложении. Создайте файл test.php и откройте его в текстовом редакторе:

Добавьте следующий код, который загружает файл vendor/autoload.php, загружает зависимость cocur/slugify и использует ее для создания ярлыка:

Сохраните файл и выйдите из редактора.

Теперь запустите скрипт:

Это приводит к выводу: привет, мир, это длинное предложение, и мне нужно сделать из него слаг .

Зависимости нуждаются в обновлении при выходе новых версий, поэтому давайте посмотрим, как с этим справиться.

Шаг 5 — Обновление зависимостей проекта

Всякий раз, когда вы хотите обновить зависимости вашего проекта до более поздних версий, запустите команду обновления:

Это проверит наличие более новых версий библиотек, необходимых для вашего проекта. Если будет найдена более новая версия и она совместима с ограничением версии, определенным в файле composer.json, Composer заменит установленную предыдущую версию. Файл composer.lock будет обновлен, чтобы отразить эти изменения.

Вы также можете обновить одну или несколько конкретных библиотек, указав их следующим образом:

Не забудьте проверить свои файлы composer.json и composer.lock после обновления зависимостей, чтобы другие могли установить эти более новые версии.

Заключение

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

Помимо предоставления простого и надежного способа управления зависимостями проекта, он также устанавливает новый стандарт де-факто для обмена и обнаружения пакетов PHP, созданных сообществом.

Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean!

Присоединяйтесь к нашему сообществу DigitalOcean, насчитывающему более миллиона разработчиков, бесплатно! Получайте помощь и делитесь знаниями в нашем разделе "Вопросы и ответы", находите руководства и инструменты, которые помогут вам расти как разработчику и масштабировать свой проект или бизнес, а также подписывайтесь на интересующие вас темы.

Читайте также: