- Серія контенту:
- Цей контент є частиною серії: Оновлений PHP
- Про це циклі статей
- Установка програмного забезпечення Composer
- Базові відомості про використання
- Яким чином інструмент Composer знаходить бібліотеки
- Конфігурація інструменту Composer для власних проектів користувача
- Малюнок 1. Інформація про бібліотеку в репозитарії Packagist
- вказівка версій
- Таблиця 1. Обмеження на версії пакету
- стабільність пакета
- Блокування версій
- Створення Автозавантажувач для Власний класів користувача
- Надання власних пакетів
- Висновок
- Ресурси для скачування
оновлений PHP
Зустрітися з потужним інструментом з відкритим вихідним кодом для збірки PHP-проектів з сторонніх бібліотек
Серія контенту:
Цей контент є частиною # з серії # статей: Оновлений PHP
http://www.ibm.com/developerworks/library/?search_by=PHP+renewed
Слідкуйте за виходом нових статей цієї серії.
Цей контент є частиною серії: Оновлений PHP
Слідкуйте за виходом нових статей цієї серії.
У зв'язку з підвищенням рівня зрілості мови PHP створені з його допомогою програми радикально ускладнилися. Сучасні PHP-розробники нерідко спираються на сторонні бібліотеки, які допомагають швидше створювати проекти програмного забезпечення. Наприклад, додаток розміром з Facebook неможливо було б створити без використання добре супроводжуваних сторонніх бібліотек, доступних сьогодні для PHP. Однак переваги повторного використання програмного забезпечення йдуть рука об руку з витратами: розробнику потрібно управляти не тільки списком бібліотек, які потрібні для кожної установки його додатки, але також і деревом залежностей, яке утворюється внаслідок того, що кожна використовувана розробником бібліотека базується на інших бібліотеках. Як чином розробнику керувати складною і взаємозалежної сукупністю безлічі бібліотек?
Два рішення для маніпулювання залежностями, які PHP-розробники широко використовували в минулому, вже пережили пік своєї ефективності. Розробнику доводилося перевіряти кожну необхідну йому бібліотеку в своєму репозитарії управління версіями разом зі своїм програмним кодом. Цей механізм працював до певної міри, проте часто породжував більше труднощів, ніж усував. Розробнику доводилося супроводжувати власну локальну версію відповідної бібліотеки. Крім того, йому потрібно було вручну реалізувати всі наявні доступні виправлення помилок для цієї бібліотеки, завантажуючи нові версії і вводячи її в репозитарій. В результаті у розробника утворювався об'ємний журнал змін в системі управління версіями, який не мав ніякого відношення до його реального коду. В результаті бібліотеки зазвичай продовжували використовуватися в тих версіях, які вони мали на початку проекту, і рідко піддавалися оновлень.
Про це циклі статей
Безперервно еволюціонуючи в рамках активного проекту з відкритим вихідним кодом, мова PHP в даний час забезпечує функціонування значної частини світового Web. Сучасний PHP значно відрізняється від тієї мови зіставлення з шаблонами, яким він був в момент свого зародження. Якщо ви багато років не використовували і не вивчали технологію PHP, то ви насилу дізнаєтеся деякі з сьогоднішніх проектів на PHP. Цей цикл статей демонструє новітні можливості PHP і розповідає, як використовувати сьогоднішню мову PHP для створення сучасних безпечних веб-сайтів.
Проект PEAR (PHP Extension and Application Repository) серед іншого мав на меті усунути і цю проблему. PEAR надає набір працюючих спільно бібліотек, що допускають розширення програмістами. PEAR також включає інструменти командного рядка для установки потрібних розробнику бібліотек разом з їх залежностями (якщо такі є в наявності). Протягом довгого часу використання сховища PEAR було найкращим підходом, що мали велику кількість прихильників, однак у цієї системи є і недоліки.
Установки PEAR-бібліотек зберігаються на глобальному рівні, в операційній системі. Хоча така організація позбавляє розробника від необхідності реєстрації бібліотек в репозитарії управління версіями, вона породжує більше проблем, ніж усуває. Розробник ніколи не знає точно, які версії бібліотеки виконуються на використовуваної ним системі. Ця плутанина часто ставала джерелом помилкових помилок. Наприклад, після установки свого застосування на новому сервері розробник міг зіткнутися з претензіями щодо працездатності програми. В кінцевому підсумку розробник розумів, що на цьому сервері просто не було належних PEAR-бібліотек. Крім того, йому був потрібний доступ, щоб встановити ці глобальні бібліотеки (з цією проблемою доводилося стикатися багатьом користувачам загального хостингу).
У квітні 2011 року PHP-розробники Нільс Адерманн (Nils Adermann) і Джорді Боджіано (Jordi Boggiano) прийшли до висновку, що PHP потрібно нове рішення для роботи з залежностями, і приступили до створення відповідного інструменту. Першого березня 2012 року ці фірми випустили інструмент під ім'ям Composer . При використанні Composer розробник створює конфігураційний файл, який визначає сторонні бібліотеки, в яких потребує його додаток (незалежно від того, де вони розміщені). Потім він запускає Composer, щоб повністю скомпонувати (compose) свій додаток. Composer завантажує всі зазначені розробником бібліотеки, а також всі залежності цих бібліотек. У статті викладаються основні відомості про Composer і демонструється використання цього інструменту в PHP-проектах.
Установка програмного забезпечення Composer
Інструмент Composer здатний працювати на різних платформах. Установка на будь-якому комп'ютері під керуванням UNIX® або Linux® не складає ніяких труднощів. Користувач може здійснити локальну установку, запустивши програму-інсталятор з допомогою утиліти curl безпосередньо в середовищі PHP.
curl -sS https://getcomposer.org/installer | php
Показана вище команда створює установку інструменту Composer в локальному файлі, що виконується composer.phar. Щоб зробити цю установку доступною глобально з будь-якого місця вашої системи, скопіюйте файл composer.phar в каталог з відповідним маршрутом, як в даному прикладі (можливо, вам доведеться за допомогою утиліти sudo надати самому собі дозвіл на запис в кореневі каталоги).
mv composer.phar / usr / local / bin / composer
Тепер команду composer можна виконати з командного рядка в будь-якому місці системі.
На комп'ютері під керуванням Windows® ручна установка складніша, тому творці Composer розробили програму-інсталятор , Яку ви можете завантажити і запустити на виконання. Після установки інструменту Composer з ним можна буде взаємодіяти з допомогою командного рядка Windows.
Базові відомості про використання
Composer - це потужний інструмент з дивним набором можливостей. Проте зазвичай ви будете використовувати цей інструмент для створення / завантаження / установки програмного коду для сторонніх PHP-додатків або інфраструктур на основі конфігурації, наданої відповідної третьою стороною. Наприклад, за допомогою Composer можна встановити інфраструктуру Zend Framework і все її залежності. Запустіть Composer за допомогою команди install, і Composer сам зробить все інше.
Якщо ви встановили Composer глобально (або в середовищі Windows), виконайте наступну команду:
composer install
Якщо ви встановили Composer локально тільки для однієї програми, виконайте наступну команду:
php composer.phar install
У прикладах для іншої частини цієї статті передбачається, що ми встановили Composer глобально.
На додаток до завантаження всіх бібліотек, необхідних вашому проекту / додатком, Composer також надає зручний спосіб включення всіх цих бібліотек. Він встановлює всі бібліотеки в папку з ім'ям vendor, щоб відрізнити їх від коду вашого власного проекту. В папці vendor Composer створює файл з ім'ям autoload.php. Результатом включення цього файлу в ваш проект є налагодження Автозавантажувач для всіх бібліотек, які інструмент Composer завантажив для вас:
require 'vendor / autoload.php';
Яким чином інструмент Composer знаходить бібліотеки
Щоб завантажити для вас пакети бібліотек, інструменту Composer для початку потрібно знати, де знайти ці пакети. Ця інформація надається репозитарій Composer: це онлайнові джерела, що містять відомості про доступні в Інтернеті пакетах, про способи їх вилучення і про їх власних залежностях. Будь-розробник може підтримувати свій власний репозитарій для надання доступу до внутрішніх бібліотекам (а веб-сайт Composer надає для цього відповідні інструкції ), Проте основним репозитарием, який ви будете використовувати, є репозитарій Packagist . Репозитарій Packagist надає пакети для більшості PHP-проектів з відкритим вихідним кодом. Ви можете звернутися в цей репозитарій, щоб знайти потрібні вам бібліотеки.
Бібліотеки програмного забезпечення далеко не завжди добре працюють разом. Сполучною ланкою для всіх бібліотек Packagist є організація PHP-FIG ( PHP Framework Interop Group ; спочатку ця організація носила назву PHP Standards Group), створена на конференції php [tek] 2009 . Організація PHP-FIG - учасники якої представляють численні популярні PHP-додатки і PHP-інфраструктури - була сформована з метою виявлення шляхів для покращення спільної роботи проектів цих учасників. Кульмінацією цієї співпраці стало створення документів типу PHP Standards Recommendation (PSR), що описують додаткові стандарти для бібліотек. Бібліотеки, які реалізують ці єдині стандарти, здатні взаємодіяти в рамках загального набору вимог.
Найважливішими є документи PSR-0 і PSR-4 , Що забезпечили створення інструменту Composer. У цих документах описується загальний метод іменування для класів і просторів імен, а також вказівки по відображенню цих імен на файли в файлової системі. У свою чергу, загальний інтерфейс autoloader здатний завантажувати класи з будь-якої потрібної бібліотеки. Саме створення спільного стандартизованого способу, що дозволяє бібліотекам спільно використовувати свої класи без взаємного перезапису, дозволило інструменту Composer стати настільки ефективним.
Конфігурація інструменту Composer для власних проектів користувача
Тепер, коли ви знаєте, як встановити інструмент Composer, розумієте, як працює автоматична завантаження, і можете відшукати пакети, які хочете використовувати, я продемонструю приклад налаштування Composer для власного проекту користувача.
Спочатку я напишу новий PHP-проект - невелику програму, яка перетворює Markdown-файли в формат HTML. Пошук в репозитарії Packagist за ключовим словом markdown пропонує бібліотеку michaelf / php-markdown в якості гарного вибору і показує URL-адресу початкової сторінки цього проекту (рис. 1).
Малюнок 1. Інформація про бібліотеку в репозитарії Packagist
Щоб повідомити інструменту Composer, які файли слід включити в наш проект, ми створюємо конфігураційний файл з ім'ям composer.json. Цей файл у форматі JSON може містити різні команди, однак найбільш поширеною (а часто і єдиною) з необхідних вам команд є ключ require. В цей ключ я передаю ім'я потрібного мені пакету і номер версії, яку я буду підтримувати.
{ "Require": { "michelf / php-markdown": "1.4. *"}}
Тепер я можу виконати директиву composer install в каталозі свого застосування. Інструмент Composer витратить кілька хвилин на завантаження необхідної бібліотеки, яку я вказав, в каталог vendor, і створить для мене автозавантажувач, що включає цей каталог. Крім того, Composer створить інший файл (з ім'ям composer.lock), який я опишу трохи пізніше. Команди вихідна інформація мають такий вигляд.
> Ls composer.json> composer install Loading composer repositories with package information Installing dependencies (including require-dev) - Installing michelf / php-markdown (1.4.1) Downloading: 100% Writing lock file Generating autoload files> ls -F composer. json composer.lock vendor /
Тепер я можу написати код, який спирається на пакет michelf / php-markdown. package. Наступний короткий PHP-скрипт зробить все, що мені потрібно.
<? Php require 'vendor / autoload.php'; use \ Michelf \ Markdown; echo Markdown :: defaultTransform (file_get_contents ( "php: // stdin"));
Інструмент Composer забезпечує мені прямолінійний і просте рішення. У обраного мною пакета Markdown немає додаткових залежностей, як це іноді буває. Але якби я вибрав пакет з залежностями, інструмент Composer автоматично витягнув би всі ці залежності одночасно і сконфігурував б їх.
вказівка версій
У файл composer.json можна включити стільки бібліотек, скільки потрібно вашому програмному забезпеченню, і для кожної з них вказати потрібну вам версію. Вказівка версій - це одне з важливих умов, дотримання яких гарантує постійну працездатність вашого програмного забезпечення. За допомогою групового символу в номері версії ви навіть можете дозволити інструменту Composer оновлювати бібліотеки від вашого імені. У попередньому прикладі я вказав версію як "1.4. *". Тепер при кожному виконанні команди composer install інструмент Composer знайде останній випуск версії 1.4 бібліотеки, але не братиме версії 1.5, 2.0 або будь-які інші вищі версії. Якби я хотів завжди отримувати останню версію бібліотеки, я міг би вказати номер версії як "*" (хоча потенційно це може викликати проблеми, якщо зміниться забезпечує API-інтерфейс).
У таблиці 1 показаний повний перелік опцій, які можна використовувати при вказівці обмежень на версії.
Таблиця 1. Обмеження на версії пакету
Специфікація Приклад Опис Точний номер версії 1.0.2 Точний номер версії пакета. Діапазон> = 1.0> = 1.0 <2.0> = 1.0 <1.1 || > = 1.2 Для завдання діапазону допустимих версій можна використовувати оператори порівняння Допускаються наступні оператори:>,> =, <, <=,! =. Можна визначити кілька діапазонів; за замовчуванням ці діапазони пов'язані логічним оператором І, при наявності роздільник (||) вони пов'язані логічним оператором АБО. Діапазон, який визначається дефісом 1.0 - 2.0 Набір версій (включаючи кінцеві значення). Груповий символ 1.0. * Шаблон з груповим символом *. 1.0. * Еквівалентно> = 1.0 <1.1. Оператор ~ ~ 1.2.3 "Наступний великий випуск". Дозволяє збільшення останньої цифри; відповідно, приклад зліва еквівалентний висловом> = 1.2.3 <1.3.0. Остання цифра може зростати. Оператор ^ ^ 1.2.3 "Наступний великий випуск". Подібний оператору ~, але допускає семантичне управління версіями і дозволяє все зміни до наступної базової версії; відповідно, приклад зліва еквівалентний висловом> = 1.2.3 <2.0.
стабільність пакета
Інше міркування щодо конфігурації інструменту Composer на предмет отримання саме тих бібліотек, які потрібні вашому проекту, полягає в тому, наскільки стабільними, на вашу думку, повинні бути випуски відповідної бібліотеки. Якщо вам потрібна найсучасніша версія або ви хочете взяти участь в тестуванні програмного забезпечення, ви можете запросити бета-версію пакету або його гілка розробки. Прапор стабільності задається шляхом його додавання в кінець рядка require з символом @. Наприклад, запросити останню версію гілки розробки пакету PHPUnit можна наступним чином:
{ "Require": { "phpunit / phpunit": "4.8.*@dev"}}
В якості довідкової інформації репозитарій Packagist показує, які галузі існують і який рядок потрібно використовувати, щоб звернутися до них ( Мал. 1 ).
Блокування версій
Одне з важливих переваг Composer полягає в тому, що розробнику не потрібно включати сторонні бібліотеки в свою систему управління версіями. При публікації нової установки свого програмного забезпечення ви можете зберегти в чистоті систему управління версіями, дозволивши інструменту Composer завантажити і конфігурувати всі бібліотеки для вас. Однак при цьому ви можете зіткнутися з проблемами. Припустимо, що для вашого веб-сайту одночасно працюють 20 серверів, на яких використовуються різні версії бібліотек, оскільки розгортання програмного коду (і виконання команди composer install) здійснювалися в різні моменти часу. Або припустимо ще більш просту ситуацію, коли кілька розробників мають різні бібліотеки і нездатні відтворювати помилки один одного. Наслідки цього можуть виявитися катастрофічними.
Інструмент Composer надає рішення для цієї проблеми. Як вже говорилося (див. Розділ " Конфігурація інструменту Composer для власних проектів користувача "), При першому виконанні команди composer install створюється файл composer.lock. Цей файл точно вказує, які бібліотеки, включаючи їх конкретні версії, були завантажені і встановлені. Коли ви передаєте свій проект в програмну систему керування версіями, передавайте файл composer.lock, але не каталог vendor. Коли нове розгортання коду буде підготовлено і команда composer install запущена, інструмент Composer спочатку буде шукати lock-файл. Якщо він знайде цей файл, то встановить точний дублікат вихідної установки, що гарантує однаковість ваших установок.
Звичайно, необхідний спосіб переходу до більш нових версій коду - бажано, щоб це було щось краще, ніж видалення lock-файлу і всього каталогу vendor. Composer надає такий спосіб у вигляді команди update. Коли ви запускаєте команду composer update, Composer порівнює версію програмного забезпечення, встановленого за допомогою lock-файлу, з останньої конфігурацією в JSON-файлі. Якщо доступні новіші версії програмного забезпечення, які допускає ваша конфігурація (або якщо після останньої установки до цієї конфігурації були додані нові бібліотеки), Composer завантажує нові бібліотеки і конфигурирует їх "за місцем".
Створення Автозавантажувач для Власний класів користувача
Інструмент Composer має ще много других вбудований можливий, Відомості про якіх містяться в его документації . Одна з найцінніших серед цих можливостей дозволяє користувачеві визначити власні класи в конфігурації, завдяки чому інструмент Composer може автоматично вбудувати код проекту цього користувача в свій автозавантажувач. Ця функціональність звільняє розробника від необхідності створення власного Автозавантажувач, незалежного від інструменту Composer.
У наступному прикладі я оновлюю попередній файл composer.json, щоб створити свій власний автозавантажувач.
{ "Require": { "michelf / php-markdown": "1.4. *"}, "Autoload": { "psr-4": { "Converter \\": "src /"}}}
У цьому прикладі я задаю простір імен Converter і вказую, що всі файли класів для цього простору імен існують всередині відносного каталогу з ім'ям src. Таким чином, якщо у мене є клас з ім'ям Converter \ CommandLine, автозавантажувач буде шукати цей клас, щоб зберегти його в файлової системі як src / CommandLine.php. Тепер цей файл є сумісним зі стандартом PSR-4 Автозавантажувач, який був згенерований для мене.
Надання власних пакетів
На цьому етапі я можу надати додаток для перетворення з Markdown в HTML у вигляді пакету для репозитария Packagist (оскільки це саме додаток, а не бібліотека, яка припускає багаторазове використання, то надання його в вигляді пакету насправді не має великого сенсу, - проте в цій вправі ми прикинемося, що насправді це бібліотека). По суті після створення мого файлу composer.json це додаток є самостійно пакетом і може бути встановлено. Ім'я цього пакету має бути представлено в форматі vendor / package. Таким чином, в моєму випадку я додаю в конфігураційний файл наступний рядок:
"Name": "EliW / Converter",
Має сенс додати і декілька інших конфігураційних налаштувань. Ми може задати необхідну версію PHP як віртуальне ім'я пакета, яке Composer буде примусово застосовувати. (Серед багатьох інших опцій ви можете примусово задати номера версій, щоб не дозволити інструменту Composer приймати стандартні шаблони системи управління версіями. Ви також можете надати метадані, щоб список пакетів виглядав завершеним.) У наступному прикладі я вказую номер версії PHP і уявляю моє додаток- конвертер у вигляді самодостатнього повного пакета.
{ "Name": "EliW / Converter", "require": { "michelf / php-markdown": "1.4. *", "Php": "> = 5.3.0"},}
Отже, конфігурація успішно виконано. Після передачі мого програми в будь-яку онлайнову систему управління версіями (наприклад, в GitHub) я можу увійти в систему зі своїм обліковим записом Packagist і представити інформацію про моє пакеті, щоб зробити це додаток доступним для включення в проекти інших розробників.
Висновок
У цій статті циклу оновлений PHP я виклав основні відомості щодо використання інструменту Composer для збірки проектів розробника з використанням сторонніх бібліотек. В онлайнової документації містяться більш докладні відомості по менш вживаним можливостям інструменту Composer. Крім того, ви можете дізнатися, як розмістити власні внутрішні бібліотеки без використання сховища Packagist для організації всієї сукупності складного коду.
У статтях даного циклу я показав, до якого рівня еволюціонував сама мова PHP, як він задовольняє сучасним вимогам до захисту і як він використовує сучасні системи управління залежностями і управління пакетами, щоб впоратися з безперервно зростаючою складністю сучасного програмного коду. У наступній статті я розгляну можливості, які сучасна екосистема PHP надає розробникам для управління своїми середовищами розробки та розгортання за допомогою інструментів Vagrant і PuPHPet.
Ресурси для скачування
Схожі тими
Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів
Com/developerworks/library/?Як чином розробнику керувати складною і взаємозалежної сукупністю безлічі бібліотек?
Lt;?