Php pear что это

PEAR посвящается Malin Bakken, родившейся 21 ноября 1999 года (первые строки PEAR были написаны всего за два часа до её рождения).

структурированная библиотека открытого кода, созданная для пользователей PHP;

система управления пакетами и распространения кода среди разработчиков;

стандарт написания PHP-кода (подробнее о стандарте см. здесь );

базовые классы PHP-кода (подробнее о базовых классах см. здесь ;

библиотека дополнительных модулей для PHP (The PHP Extension Code Library, PECL), подробную информацию о PECL можно узнать здесь ;

Есть два типа пакетов: пакеты исходного кода (содержат, соответственно, только исходники) и бинарные пакеты (содержат платформозависимые бинарные файлы и, возможно, их исходный код). Естественно, что установка пакетов, которые содержат код на C, из исходников требует присутствия среды для компиляции C-кода.

В PEAR существует определенное дерево пакетов, в котором каждой ветвью является часть имени пакета. Ветви разделяются по темам, их названия в именах пакетов разделяются символом подчеркивания. Например, «MP3_Id», «Archive_Tar» и «HTTP_Post».

Пакеты могут находиться в зависимости друг от друга, однако не существует какой-либо обязательной зависимости между пакетом и его «родителем» в дереве пакетов (например, «HTTP_Post» не зависит от «HTTP»).

Все пакеты PEAR регистрируются и загружаются в центральную базу данных, которая доступна на pear.php.net. Сторонние пакеты с открытыми исходниками так же могут быть зарегистрированы и загружены. Пакеты с закрытыми исходниками PEAR предназначена только для кода с открытыми исходниками.

Pear.php.net предоставляет два варианта интерфейсов к базе данных PEAR: дружественный для пользователя интерфейс (HTML) и интерфейс для машины (на данный момент это XML-RPC). Загрузка пакетов осуществляется с помощью HTTP. Также, pear.php.net выполняет и другие функции:

управление пользовательскими записями (интегрированное с сервером CVS)

управление релизами пакетов

Пакеты распространяются в виде архивов *.TAR.GZ с описанием в формате XML. Описание содержит информацию о пакете, список файлов и их предназначений, а также список зависимостей.

Повышенное качество этих пакетов означает то, что ни один пакет с уровнем ниже «stable» не будет допущен в PFC.

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

Многофункциональность пакетов означает, что их удобно использовать в других пакетах, они имеют стабильный и стандартизированный API, предпочитают использовать устоявшиеся компоненты, а также не зависят от внешней среды (версии PHP, SAPI, операционной системы и др.)

На данный момент еще нет определенного плана о том, как они будут распространяться.

Источник

Что это такое: PEAR?

структурированная библиотека открытого кода, созданная для пользователей PHP;

система управления пакетами и распространения кода среди разработчиков;

стандарт написания PHP-кода (подробнее о стандарте см. здесь);

базовые классы PHP-кода (подробнее о базовых классах см. здесь;

библиотека дополнительных модулей для PHP (The PHP Extension Code Library, PECL), подробную информацию о PECL можно узнать здесь;

Структурированная библиотека PHP-кода

Есть два типа пакетов: пакеты исходного кода (содержат, соответственно, только исходники) и бинарные пакеты (содержат платформозависимые бинарные файлы и, возможно, их исходный код). Естественно, что установка пакетов, которые содержат код на C, из исходников требует присутствия среды для компиляции C-кода.

В PEAR существует определенное дерево пакетов, в котором каждой ветвью является часть имени пакета. Ветви разделяются по темам, их названия в именах пакетов разделяются символом подчеркивания. Например, «MP3_Id», «Archive_Tar» и «HTTP_Post».

Пакеты могут находиться в зависимости друг от друга, однако не существует какой-либо обязательной зависимости между пакетом и его «родителем» в дереве пакетов (например, «HTTP_Post» не зависит от «HTTP»).

Несколько ветвей высшего уровня называются «суб-репозиториями» и выполняют специальные функции. На данный момент это: PECL, Gtk и App. Каждый из них достоин отдельной темы, поэтому за дополнительной информацией лучше обратиться в соответствующие разделы настоящей документации.

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

Все пакеты PEAR регистрируются и загружаются в центральную базу данных, которая доступна на pear.php.net. Сторонние пакеты с открытыми исходниками так же могут быть зарегистрированы и загружены. Пакеты с закрытыми исходниками PEAR предназначена только для кода с открытыми исходниками.

Pear.php.net предоставляет два варианта интерфейсов к базе данных PEAR: дружественный для пользователя интерфейс (HTML) и интерфейс для машины (на данный момент это XML-RPC). Загрузка пакетов осуществляется с помощью HTTP. Также, pear.php.net выполняет и другие функции:

управление пользовательскими записями (интегрированное с сервером CVS)

управление релизами пакетов

Пакеты распространяются в виде архивов *.TAR.GZ с описанием в формате XML. Описание содержит информацию о пакете, список файлов и их предназначений, а также список зависимостей.

Базовые классы PHP

Повышенное качество этих пакетов означает то, что ни один пакет с уровнем ниже «stable» не будет допущен в PFC.

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

Многофункциональность пакетов означает, что их удобно использовать в других пакетах, они имеют стабильный и стандартизированный API, предпочитают использовать устоявшиеся компоненты, а также не зависят от внешней среды (версии PHP, SAPI, операционной системы и др.)

Библиотека дополнительных модулей для PHP (PECL)

Пакеты Gtk

На данный момент еще нет определенного плана о том, как они будут распространяться.

Источник

PEAR – PHP Extension and Application Repository

Руководство для начинающих

Автор: Дмитрий Димандт aka Mamut
Источник: RSDN Magazine #5-2004

Опубликовано: 30.03.2005
Исправлено: 10.12.2016
Версия текста: 1.0

Что такое PEAR

PEAR расшифровывается как P HP E xtension and A pplication R epository, база расширений и приложений для PHP. Но что же это действительно значит?

Представьте, что Ваш проект использует MySQL в качестве базы данных. PHP предоставляет вам встроенные средства для работы – функции mysql_* или (начиная с версии 5.0) расширение mysqli. У вас есть десятки файлов, содержащих примерно следующий код:

В один прекрасный день ваш шеф говорит, что политика компании изменилась, и что отныне вам придется иметь дело с Oracle, PostgreSQL или (боже упаси!) MSSQL. Что Вам приходится делать? Рвать на себе волосы и биться головой об стенку. Так как количество кода неимоверно, а слепая замена mysql_* на ora_* не пойдет.

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

Структурированная библиотека открытого кода

Чтобы понять, что это такое, советую посмотреть список «пакетов», доступных в PEAR. Глаза разбегаются от разнообразия. Авторизация, работа с датами и временем, работа с файловой системой, базы данных, HTTP и так далее…

Код в PEAR разделен на так называемые «пакеты» (packages). Каждый из пакетов – набор классов и утилит, написанных на PHP и представляющих собой решение какой-нибудь распространенной проблемы.

Каждый пакет – детище одного или нескольких программистов, решивших облегчить жизнь самим себе, а в итоге облегчающих жизнь нам с Вами. Более того, пакеты, прошедшие тщательную проверку, включаются в дистрибутив PHP и получают название базового класса (PHP Foundation Class). Так, например, DB и HTTP являются базовыми классами PHP.

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

Классы PEAR и PEAR_Error

Б о льшая, но не вся, часть пакетов в PEAR опирается на классы PEAR и PEAR_Error, определенные в пакете… PEAR.

Класс PEAR

В версиях PHP меньше 5.0, и в пакетах, еще не перешедших на 5.0, этот класс эмулирует деструкторы в наследуемых классах.

Для того чтобы эмуляция срабатывала, необходимо создавать объекты по ссылке, т.е.

Этот класс имеет метод isError($obj), определяющий, является ли тот или иной объект объектом PEAR_Error.

Класс PEAR_Error

Используется для создания стандартизированых сообщений об ошибках.

Установка

Ниже приводится последовательность шагов, необходимых для использования пакетов PEAR, на примере пакета DB. Предупреждаю сразу, предложенный ниже способ отличается от официального (http://pear.php.net/manual/ru/installation.php). Предлагаемый мною способ универсален, работает на любых конфигурациях PHP и сервера.

2. Распакуйте архив в какую-нибудь директорию.

3. Для дальнейшей работы из всей кучи файлов понадобится только PEAR.php. Если в работе понадобятся платформенно-независимые системные функции (определение текущей ОС на сервере, рекурсивный обход директорий, удаление директорий и проч.), взгляните также на файл System.php.

4. Создайте в структуре вашего сайта директорию pear/ и скопируйте PEAR.php туда. Теперь все готово к работе.

5. Рассмотрим дальнейшие действия на примере использования в проекте пакета DB, служащего для унифицированого доступа к базам данных. Зайдите на http://pear.php.net/package/DB и скачайте этот пакет.

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

Summary – краткое описание пакета. Обычно – емкое название, его характеризирующее.

License – лицензия, на условиях которой пакет выпускается. Несмотря на то, что пакеты в PEAR рекомендуется публиковать на условиях PHP License, некоторые пакеты выпускаются на условиях GNU Public License. На это стоит обратить внимание при работе над коммерческим проектом.

Current Release – текущая версия пакета.

Description – описание пакета.

6. Распакуйте пакет DB.

7. Скопируйте файл DB.php и поддиректорию DB/ в директорию pear/ вашего сайта.

8. Откройте файл DB.php в вашем любимом редакторе, найдите строчку require_once ‘PEAR.php’; и сотрите ее. Сохраните файл.

9. В корневом каталоге сайта создайте файл testdb.php. Структура сайта должна выглядеть примерно так:

10. В файл testdb.php впишите следующее:

11. Проверьте файл на работоспособность. Как видите – ни одной ошибки : ) Правда, это не значит, что все работает.

12. Добавьте в файл testdb.php следущий код:

Все. Теперь вы знаете, как подключить любой пакет из PEAR.

Документация

Как известно, программисты – тоже люди и ничто человеческое им не чуждо. Также им не чужда лень и патологическое нежелание писать документацию к своим творениям. Увы, авторы пакетов PEAR – не исключение, и полноценная документация к пакетам встречается нечасто.

Неужели все так плохо? – спросите вы, окидывая взглядом необъятные просторы PEAR. Нет, на самом деле все не так плохо.

Одним из условий принятия пакета в PEAR – ясный, хорошо документированый код. На основе исходников к каждому пакету автоматически генерируются описания классов и их методов, так что, как минимум, общее представление о пакете у вас все же будет. Авторы многих пакетов пишут дополнительную документацию, которая также прилагается к пакетам. Плюс, каждый пакет поставляется с примерами использования, или такие примеры можно легко найти в исходных кодах самого пакета (иногда описание классов и примеры занимают чуть ли не большую часть исходных файлов).

Собранную на текущий момент документация по PEAR можно найти по адресу http://pear.php.net/manual/index.php.

Будущее PEAR

Многие, прочитав статью и увидев упор на решения, использующие базы данных, могут махнуть на PEAR рукой, указав на появившееся в PHP5 расширение mysqli. Другие, обнаружив, что PEAR бесплатен и разрабатывается на общественных началах, также махнут на него рукой и сядут разрабатывать свою собственную систему. Третьи, решив, что главная задача PEAR – эмуляция объектной ориентации (например, эмуляция деструкторов, предлагаемая классом PEAR), махнут рукой, забудут про PEAR и перейдут на PHP5.

И те и другие, и третьи будут неправы. Появление на сцене PHP5 с новыми расширениями и улучшенной поддержкой объектно-ориентированого программирования никоим образом не влияет на PEAR, который прежде всего является базой готовых, работающих решений для очень большого спектра проблем.

И так далее. Шифрование, авторизация, работа с изображениями, а также многое другое. Достаточно взглянуть на список предлагаемых пакетов (http://pear.php.net/packages.php).

Основная задача разработчиков PEAR сейчас – стабилизация уже существующего кода и приведение всех пакетов в соответствие со стандартом (http://pear.php.net/manual/ru/standards.php). На сайте действует система отслеживания багов, где можно сообщить о найденных ошибках или предложить изменения/дополнения к существующим пакетам. Условия приема пакетов способствуют тому, что код в исходных файлах четко и ясно написан, а также документирован, что облегчает их использование. Состояние PEAR отслеживается в еженедельных публикациях на сайте разработчиков PHP – Zend Group, а «мертвые» (находящиеся в ранней стадии разработки и давно не обновляемые) пакеты удаляются из базы.

PEAR – это динамичная развивающаяся среда, предлагающая все новые и новые решения разработчикам.

Источник

Расцвет Composer и закат PEAR

[Дабы не возникло недопонимания, стоит пояснить, что автор оригинального текста — Fabien Potencier, создатель популярного PHP фреймворка Symfony — прим. пер.]

Совсем недавно, Nils Adermann, прислал мне милую открытку, в напоминание о нашей встречи три года назад на “SymfonyLive hackday” в Сан-Франциско. Nils присутствовал на конференции, т.к. за год до этого, он анонсировал, что phpBB в версии 4 перейдет на Symfony.

В то время, я серьезно интересовался темой менеджеров пакетов, ибо искал удобный способ управлять бандлами в Symfony2. Для плагинов в Symfony1 я использовал PEAR, но код был очень запутанным, ведь PEAR изначально создавался немного не для этого. Философия Бандлера из Ruby сообщества выглядела очень привлекательно, так что я начал поиски подобного пакетного менеджера. После долгих бессонных ночей, я наткнулся на libzypp, и моментально понял, что это оно! К сожалению libzypp — сложная библиотека, написанная на C, и в таком виде, совсем не подходила для Symfony.

Я смекнул, что хорошим менеджером пакетов, позволяющим пользователям легко устанавливать плагины/бандлы/моды наверняка интересуется и Nils, для phpBB, так что я завел об этом разговор на hackday в Сан-Франциско. Оказалось, что в то время, Нилс уже начал работу над Composer.

Нилс проделал потрясающую работу по переводу C кода в PHP код. Позже, присоединившийся к команде Джорди вывел все на новый уровень, взяв на себя заботы по реализации всей инфраструктуры проекта.

Так, что насчет PEAR? PEAR верой и правдой служил PHP сообществу много лет, думаю настало время, дать ему умереть.

Я использовал PEAR в качестве менеджера пакетов еще с моего первого проекта на PHP в далеком 2004-м. Я даже написал популярный сервер каналов Pirum. Но сейчас настало время двигаться дальше, и рассказать о своих планах на каналы, которыми я управляю.

13 февраля я писал в твиттере, что собираюсь перестать поддерживать свои пакеты в PEAR, т.к. Composer уже достаточно популярен. 14 февраля я решил перестать работать над Pirum.

Так как многие хотели узнать статистику канала Symfony, я залез в логи, и обнаружил, что большинство запросов идет от зависимостей PHPUnit. 20-того апреля Sebastian Bergmann открыл обсуждение о поддержке PEAR для PHPUnit. На следующий день, он опубликовал сообщение, в котором прощался с PEAR. Чуть позже, Pádraic Brady также отказался от поддержки PEAR канала для Mockery.

Кроме Symfony, в моем ведении также находятся каналы Twig, Swiftmailer и Pirum. И вот мои планы:

Заметьте, что я говорю о прекращении выпуска НОВЫХ пакетов в PEAR, и продвижении Composer как основного средства для инсталляции моих библиотек и проектов. Уже существующие пакеты, в обозримом будущем, все еще можно будет ставить через PEAR.

Источник

Статья Стандарты кодирования Pear

Вот вам стандарты PHP-кодирования. Не смотря на то, что он был разработан PEAR для использования в своих целях, следует знать, что очень многое можно использовать и в повседневной работе. Трудно изменить стиль оформления своих работ, не смотря на это, постарайтесь взять в свой стиль программирования как можно больше из этого мануала.
Ниже прикреплен полный русский PEAR FAQ.
Для начала давайте узнаем, что такое PEAR?

Используйте для отступа 4 пробела, а не табуляцию. Если вы используете Emacs для редактирования кода, вы должны установить indent-tabs-mode в ноль. Ниже приведен пример настройки Emacs для этой цели:

Управляющие структуры
Управляющие структуры включают в себя операторы if, for, while, switch, и др. Ниже приведен пример оформления оператора if, который в этом отношении является самым сложным:

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

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

Cинтаксис оператора switch:

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

Определения функций
Определения функций следуют такому cоглашению:

Комментарии
Комментарии внутри кода классов должны соответствовать синтаксису комментариев PHPDoc, который напоминает Javadoc. За дополнительной информацией о PHPDoc обращайтесь сюда: http://www.phpdoc.org/

Подходят комментарии в стилях C (/* */) и C++ (//). Использование комментариев в стиле Perl/shell (#) не рекомендуется.

Подключение кода (including)
В тех местах, где вы используете подключение файлов других классов вне зависимости от условий, используйте конструкцию require_once(). Если же подключение файлов зависит от каких-либо условий, то следует использовать include_once(). В этом случае вы всегда будете уверены в том, что файлы подключаются только единожды.

Замечание: include_once() и require_once() и являются конструкциями, а не функциями. Вам не обязательно использовать скобки вокруг имени файла, который подключается.

Тэги PHP-кода
Всегда используйте вместо для выделения PHP-кода. Это необходимо для обеспечения работы PEAR на разных операционных системах и с различными настройками.

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

Нет четкого правила, которое определяет момент, когда новый разработчик должен быть добавлен в список авторов данного файла. В общем случае, его внос в изменения этого файла должен относиться к категории «значительных» (т.е. около 10%-20% процентов кода). Исключения могут быть в случае переписывания функций или добавления новой логики.

Простая реорганизация кода и исправление ошибок не приводит к добавлению нового участника в список авторов.

Файлы, которые не входят в базовую часть PEAR должны такой же блок комментариев в заголовке, включая авторские права, лицензию и список авторов. Комментарии должны быть отформатированы для того, чтобы сохранять свою целостность.

Использование CVS
Эта часть касается только пакетов, использующих CVS на cvs.php.net.

В оставшейся части этой главы предполагается, что вы имеете представление о тэгах CVS и ветках (branches).

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

RELEASE_n_n
(обязательный) Используется для пометки релиза. Если вы не используете его, то вы не сможете вернуться назад и затребовать пакет в том виде, в котором он находился во время прошлого релиза.

QA_n_n
(необязательный) Если вы чувствуете, что перед выпуском релиза необходимо выпустить предварительную версию (release candidat), то вы можете сделать ветку (branch) кода для того, чтобы изолировать релиз и вносить только критически важные изменения до релиза. При этом, обычный процесс разработки может продолжаться в основном дереве кода.

MAINT_n_n
(необязательный) Если вам нужно сделать «микро-релиз» (например, версию 1.2.1 и т.п. после 1.2), вы так же можете использовать ветку в том случае, если основной код меняется достаточно активно и вы хотите вносить только небольшие изменения в микро-релизы.

Обязательным является только тэг RELEASE, остальные рекомендуются для вашего же удобства.

Пример того, как пометить тэгом релиза 1.2 пакет «Money_Fast»:

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

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

Примеры URLов
Используйте «example.com» для примеров URLов, как описано в RFC 2606.

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

Классы
Имена классов должны быть удобочитаемыми и понятными. Избегайте использования аббревиатур там, где это возможно. Имена классов должны начинаться с буквы в верхнем регистре. Иерархия классов PEAR также отражается на именах классов, каждый уровень отделяется знаком подчеркивания. Примеры хороших имен классов:

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

Константы
Имена констант всегда должны быть в верхнем регистре с подчеркиваниями для разделения слов. В качестве префикса в именах констант должно использоваться имя пакета/класса, в котором они используются. Например, все константы, которые используются в пакете DB. начинаются с «DB_».

Встроенные переменные TRUE, FALSE, NULL
Встроенные переменные PHP TRUE, FALSE and NULL должны быть написаны в нижнем регистре.

Источник