Статьи

Включение PHP библиотек через Composer

Октябрь 5, 2018

Эта статья представляет собой обзор
Composer , новой системы управления пакетами PHP, которая направлена ​​на решение проблемы совместного использования кода.

Отличия от PEAR

Composer управляет библиотеками для каждого проекта вместо установки общесистемных пакетов, как это делает PEAR. Он управляет зависимостями, в комплекте с указанной веткой или версией, больше, чем пакеты или инструменты разработчика. Этот подход был вдохновлен менеджером пакетов Node, npm.

Рекурсивные зависимости (библиотеки, которые зависят от других библиотек), конечно, поддерживаются как в PEAR, так и в Composer; PEAR имеет параметр autodiscover, чтобы решить проблему с несколькими каналами, в то время как Composer показывает каждый пакет на packagist.org.

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

вопросы

Таким образом, существует потенциально две критики модели Composer: проблема захвата исходного кода вместо сборки пакета (содержащего тесты и другое оборудование вместе с исходным кодом) и наличие единой точки отказа, где перечислены все пакеты, Packagist ,

Проблема захвата всего источника проекта связана с простотой. Например, приобретая PHPUnit_Selenium с помощью Composer (* composer * repository), вы также удалите его набор тестов и несвязанные файлы, например папку, полную образцов HTML-страниц. С Composer у вас есть все, что нужно для разработки зависимости, а не только для ее использования.

Следует добавить, что Composer не заставляет вас это делать, поскольку теперь он поддерживает также в зависимости от пакетов PEAR или даже просто из zip-файлов. Чего не хватает, так это стандартного репозитория для собранных пакетов, но если у вас уже есть ваш PEAR-канал, вы можете опубликовать на нем свои сборки, и мы сможем их установить.

Единая точка отказа является Packagist центрального хранилища, который постоянно перестраивает доступные пакеты путем сканирования исходных репозиториев зарегистрированных проектов. Можно клонировать приложение с открытым исходным кодом и разместить собственный (внутренний или общедоступный) репозиторий пакетов. В настоящее время это невозможно, перечислив встроенные пакеты в Packagist; но единственная проблема, связанная с ошибкой, более актуальна, поскольку отказ одного веб-сайта может взять на себя сообщество PHP.

Установка

Установка Composer действительно проста:

curl -s http://getcomposer.org/installer | php -- --install-dir=bin

Я положил его в папку ~ / bin, так как он находится на моем пути; если вы сделаете то же самое, вы сможете просто ввести composer.phar в качестве команды отовсюду.

Пример проекта

Одной из распространенных проблем, связанных с зависимостями, является импорт ORM, подобного Doctrine 2. В этом примере мы определяем зависимость от doctrine-orm, которая зависит от doctrine / dbal и, в конечном счете, также от doctrine / common.

Все метаданные должны быть записаны в файл composer.json на верхнем уровне проекта:

{
    "require": {
        "doctrine/orm": "2.2.1"
    }
}

Будучи проектом, поддерживающим Composer, Doctrine 2 ORM перечисляет свои собственные зависимости, и нам требуется только основной пакет, который нам нужен.

Выполнение: 

$ composer.phar install

загрузка пакетов займет несколько секунд с субъективно более быстрым протоколом, чем у PEAR.

Вот конечный результат:

$ tree -L 4
.
├── composer.json
├── composer.lock
└── vendor
    ├── bin
    └── doctrine
        ├── common
        │   ├── build.properties
        │   ├── build.xml
        │   ├── composer.json
        │   ├── lib
        │   ├── LICENSE
        │   ├── phpunit.xml.dist
        │   ├── README.md
        │   ├── tests
        │   ├── UPGRADE_TO_2_1
        │   └── UPGRADE_TO_2_2
        ├── dbal
        │   ├── bin
        │   ├── build.properties
        │   ├── build.xml
        │   ├── composer.json
        │   ├── lib
        │   ├── LICENSE
        │   ├── phpunit.xml.dist
        │   ├── README.md
        │   ├── run-all.sh
        │   ├── tests
        │   └── UPGRADE
        └── orm
            ├── bin
            ├── build.properties
            ├── build.properties.dev
            ├── build.xml
            ├── composer.json
            ├── doctrine-mapping.xsd
            ├── lib
            ├── LICENSE
            ├── phpunit.xml.dist
            ├── README.markdown
            ├── run-all.sh
            ├── tests
            ├── tools
            ├── UPGRADE_TO_2_0
            ├── UPGRADE_TO_2_1
            ├── UPGRADE_TO_2_2
            ├── UPGRADE_TO_ALPHA3
            └── UPGRADE_TO_ALPHA4

15 directories, 32 files

Композитор не только загрузил проекты и поместил их в вендор /, но также создал файлы автозагрузки:

<?php
require_once 'vendor/.composer/autoload.php';
// searches for the class allowing autoloaders to be called
var_dump(class_exists('Doctrine\ORM\EntityManager', true)); // dumps bool(true)

Обратите внимание, что также создается файл composer.lock, содержащий информацию о разрешенных версиях зависимостей. Например, если вы зависите от Doctrine 2, указав 2. * в качестве версии, файл блокировки будет содержать 2.2.1. Вы можете либо зафиксировать файл блокировки, если вы хотите воспроизводимую сборку (мой выбор для проектов), либо заставить VCS игнорировать его для простоты, если вы не хотите периодически обновлять его вручную.

43
Share: