Comments 80
egg в Python, имхо, реализованы в 100500 раз удобнее. Про Jar ничего не знаю.
Было бы здорово включить в статью элементарное объяснение зачем это нужно. Кроме очевидного «один файл вместо кучи». Спасибо.
Для инсталяторов, нет?
Если учесть, что производительность от этого не страдает, то этого, по-моему, вполне достаточно.
А Вам даже этого разве мало?
Так же можно сказать о чем угодно:
— зачем использовать ORM, кроме очевидного «данные из БД представлены в ввиде объектов»?
— зачем нужны акселераторы, кроме очевидного «ускорение исполнения скрипта»?
— …
Использовать PHAR, или нет — решать Вам. Если чувствуете, что удобно — используете, если нет — никто не заставляет :)
Так же можно сказать о чем угодно:
— зачем использовать ORM, кроме очевидного «данные из БД представлены в ввиде объектов»?
— зачем нужны акселераторы, кроме очевидного «ускорение исполнения скрипта»?
— …
Использовать PHAR, или нет — решать Вам. Если чувствуете, что удобно — используете, если нет — никто не заставляет :)
Я не говорил мало это или много. Я просил описать проблемы, которые решает phar. Если это только количество файлов, то так и написать. Я нигде не написал что этого недостаточно, вы нафантазировали. Просто не увидел других очевидных преимуществ и попросил подсказать.
Не принимайте мой комментарий в штыки, пожалуйста.
А штыки я чем показал? Запятую где-то пропустил? Или восклицательный знак поставил? Вы меня изначально неправильно поняли. Я прошу описать преимущества подхода, а вы воспринимаете это как сарказм. Далее пишу о том, что я не шучу, мне действительно интересно зачем, и, опять, меня не понимают. Я не пришел потроллить на тему «ещё одна бесполезная фича», я хочу узнать зачем это нужно. «Один файл вместо 1000» — это хорошо, но об этом я и сам догадался. Хотел услышать что-то ещё, если это есть.
1) чтобы закачивать по (s)ftp меньше файлов;
2) запаковать нечто, имеющее конкретную версию и не подлежащее изменению в рамках этой версии (библиотека, модуль, cms, и т.п.).
2) запаковать нечто, имеющее конкретную версию и не подлежащее изменению в рамках этой версии (библиотека, модуль, cms, и т.п.).
Например клиент для работы с каким-либо API сервером из консоли. Очень удобно имея один псевдобинарник.
А можно реальные ситуации где это надо? А если еще и бенчмарки выложите… :)
Вот зачем нужно: http://habrahabr.ru/blogs/symfony/118011/ Ну или: http://silex-project.org/installation
Спустя два месяца:
Using the Silex phar file is deprecated. You should use Composer instead to install Silex and its dependencies or download one of the archives.
silex.sensiolabs.org/doc/phar.html
Using the Silex phar file is deprecated. You should use Composer instead to install Silex and its dependencies or download one of the archives.
silex.sensiolabs.org/doc/phar.html
например, у вас есть модульная cms и модули к ней удобно делать в виде phar
> метода getSub()
плиз, поправьте на getStub()
опечатались
плиз, поправьте на getStub()
опечатались
Когда же php пройдет уже…
Когда же идиоты пройдут уже…
Сколько ненависти то в PHP разработчиках, бедняги.
Уже больше 30 человек не хотят чтобы он проходил )). Что ж, я рад за вас, потому что это значит что вы встречаете только лаконичный, грамотный и чистый php код, написаный профессионалами, и всегда верный. Или вы очень терпимы к ошибкам школьников и т.д., примеры которых предостаточно везде.
Было бы вас побольше таких, тогда бы не было комментариев по типу моего.
А я перехожу в node.js. Всем удачи.
Было бы вас побольше таких, тогда бы не было комментариев по типу моего.
А я перехожу в node.js. Всем удачи.
Когда mod_wsgi/mod_rack/… будут ставиться всеми хостерами по дефолту за те же деньги, что сейчас ставят mod_php. Когда для типовых задач будут готовые решения (причём по 100500 на каждую задачу на любой вкус) по принципу «закачал по ftp, прописал доступ к БД (также по ftp) и работает», а то и просто «поставил галочку в админке аккаунта». Когда будут простые (для «веб-мастеров») CMS типа, прости господи, WordPress или Joomla. И т. д., и т. п.
Языки типа python/ruby или Java/C# не сложнее, а во многом и проще PHP, имхо. Но вот пресловутый порог входа для создания своих или использования готовых веб-приложений, имхо, явно выше у них. Хотя бы потому, что сам язык является мини-фреймворком, абстрагирующим детали реализации HTTP, а для других языков нужно или эти фреймворки устанавливать (ещё выбирать, потом изучать), или реализовывать HTTP самому.
Языки типа python/ruby или Java/C# не сложнее, а во многом и проще PHP, имхо. Но вот пресловутый порог входа для создания своих или использования готовых веб-приложений, имхо, явно выше у них. Хотя бы потому, что сам язык является мини-фреймворком, абстрагирующим детали реализации HTTP, а для других языков нужно или эти фреймворки устанавливать (ещё выбирать, потом изучать), или реализовывать HTTP самому.
> он должен местить в своем названии
украинизм
украинизм
аналог JAR в Java
Т.е. вместо десятка директорий (=пространств имен) содержащих по несколько сотен директорий и файлов можно положить всего десяток phar архивов и подключать файлы из них? Производительность при этом не пострадает? Или phar все же больше предназначен для создания инсталяторов (=распаковать файлы в нужно место)?
именно так, можно вообще ничего явным образом не подключать.
В статье действительно очень хорошо описано как распаковывать и запаковывать, но вот люди не знакомые с джавой могут перепутать с эгами или гемами:) Использование именно для инсталяторов мне видится сомнительным, уверен есть решения получше и для визардов установки и темболее для деплоймента. А вот упаковать проект всеми либами и фреймворками нужных версий от которых он зависит с такой штукой намного проще.
Все это добро должно разворачиваться во временные каталоги, т.е. производительность при подключении напрямую теряться не должна
В статье действительно очень хорошо описано как распаковывать и запаковывать, но вот люди не знакомые с джавой могут перепутать с эгами или гемами:) Использование именно для инсталяторов мне видится сомнительным, уверен есть решения получше и для визардов установки и темболее для деплоймента. А вот упаковать проект всеми либами и фреймворками нужных версий от которых он зависит с такой штукой намного проще.
Все это добро должно разворачиваться во временные каталоги, т.е. производительность при подключении напрямую теряться не должна
С jar-ами то все понятно — они изначально были для упаковки классов и ресурсов, а вот с phar-ами не совсем, т.к. если производительность теряется, то в большинстве случаев смысла в них нет (упаковывать лучше и проще в архивы).
А это не первая статья про phar на хабре в которой подробно описаны действия с архивами, но нет столь же подробного объяснения зачем они нужны. Отсюда и вопросы.
В статье действительно очень хорошо описано как распаковывать и запаковывать
А это не первая статья про phar на хабре в которой подробно описаны действия с архивами, но нет столь же подробного объяснения зачем они нужны. Отсюда и вопросы.
The phar extension provides a way to put entire PHP applications into a single file called a «phar» (PHP Archive) for easy distribution and installation. In addition to providing this service, the phar extension also provides a file-format abstraction method for creating and manipulating tar and zip files through the PharData class, much as PDO provides a unified interface for accessing different databases.
ru.php.net/manual/en/intro.phar.php
т.е. мнению разработчиков фар является штукой для удобной инсталяции и дистрибуции и вдобавок является хорошей абстракцией для работы с архивами
phar.cache_list this INI setting was added in phar 2.0.0 Allows mapping phar archives to be pre-parsed at web server startup, providing a performance improvement that brings running files out of a phar archive very close to the speed of running those files from a traditional disk-based installation.
www.slideboom.com/presentations/26182/PHP-5.3-Part-3---Introducing-PHAR
т.е. если чуть подшаманить в приложении или настройках сервера то уступать будет совсем немного, как обычно вобщем:)
ru.php.net/manual/en/intro.phar.php
т.е. мнению разработчиков фар является штукой для удобной инсталяции и дистрибуции и вдобавок является хорошей абстракцией для работы с архивами
phar.cache_list this INI setting was added in phar 2.0.0 Allows mapping phar archives to be pre-parsed at web server startup, providing a performance improvement that brings running files out of a phar archive very close to the speed of running those files from a traditional disk-based installation.
www.slideboom.com/presentations/26182/PHP-5.3-Part-3---Introducing-PHAR
т.е. если чуть подшаманить в приложении или настройках сервера то уступать будет совсем немного, как обычно вобщем:)
UFO just landed and posted this here
Да за 2-е я бы сам пальчики ломал.
UFO just landed and posted this here
Кстати говоря, иногда удобно «быстро поправить».
Например, локально все работает, вылили на devel сервак, а там — ошибка.
Подумали, поправили локально, закоммитили, вылили… Все равно ошибка!
Или же просто зайдем на сервак, правим один файл, находим проблему и уже делаем правльный deploy.
Например, локально все работает, вылили на devel сервак, а там — ошибка.
Подумали, поправили локально, закоммитили, вылили… Все равно ошибка!
Или же просто зайдем на сервак, правим один файл, находим проблему и уже делаем правльный deploy.
Ещё в использовании .phar есть одна классная фишка: можно вшивать в него autoload-еры для классов. Пример реализации:
Полную версию примера см. тут.
$phar->setStub('<?php
Phar::mapPhar("Lagger");
function autoloadLaggerByDir($class) {
if(strpos($class, "Lagger_") === 0) {
require_once("phar://" . str_replace("_", DIRECTORY_SEPARATOR, $class) . ".php");
}
}
spl_autoload_register("autoloadLaggerByDir");
__HALT_COMPILER();
');Полную версию примера см. тут.
Расширение phar использует т. н. «перехватчики» функций, в том числе функций ядра. Я сталкивался со случаем, когда в одной из ранних версий phar сломали функцию is_file(), и с тех пор как-то настороженно отношусь к этому расширению, и предпочитаю его не включать.
"… длина названия не должна превышать 255 бит"
Штоу? Может байт?
Штоу? Может байт?
Если изначально делать веб приложение в одном архиве, то переносить на другой хостинг будет на много быстрее.
UFO just landed and posted this here
В зависимости как у вас процесс деплоя устроен. Самый простой сценарий: кодите как обычно без phar, комит, какой-нить ci сервер подхватывает новую ревизию, пакует в phar, деплой.
UFO just landed and posted this here
Архивом проще оперировать, чем деревом каталогов и файлов. В принципе можно обойтись и простым tar.gz при деплое, я не спорю, но такой архив нужно распаковать при деплое. phar будет достаточно подменить.
Я написал всего лишь один из юс-кейсов. Другой вариант деплоя, билд можно и локально организовать. Написали код, пускаете phing, он вам все тесты прогоняет, стиль кодинга проверит, нагенерит миграций и упакует все в phar. Дальше делайте с ним что хотите: лейте по фтп, высылайте по мылу или еще что.
В общем, пусть человек который видит выгоду в phar использует его, если выгоды не видно, то можно и по-старинке, раньше ж как-то выживали :)
P.S. Сразу видно кто имел дело с java и их jar, а кто нет ;)
Я написал всего лишь один из юс-кейсов. Другой вариант деплоя, билд можно и локально организовать. Написали код, пускаете phing, он вам все тесты прогоняет, стиль кодинга проверит, нагенерит миграций и упакует все в phar. Дальше делайте с ним что хотите: лейте по фтп, высылайте по мылу или еще что.
В общем, пусть человек который видит выгоду в phar использует его, если выгоды не видно, то можно и по-старинке, раньше ж как-то выживали :)
P.S. Сразу видно кто имел дело с java и их jar, а кто нет ;)
> Архивом проще оперировать, чем деревом каталогов и файлов
На этом можно было остановиться. Остальное просто вода.
В большинстве случаев jar именно поэтому и используется. И мы можем забыть про чексуммы, цифровые подписи, манифесты и прочие плюшки jar — это все ни к месту здесь и из другой оперы.
> P.S. Сразу видно кто имел дело с java и их jar, а кто нет ;)
и это все ни к месту и указывает лишь на узкость вашего мышления. когда же люди научатся комментарии давать по существу?
Действительный итог: Архивом проще оперировать, чем деревом каталогов и файлов.
Все остальные плюшки реализуются не jar'ом, а инструментами. Jar = обычный zip архив.
На этом можно было остановиться. Остальное просто вода.
В большинстве случаев jar именно поэтому и используется. И мы можем забыть про чексуммы, цифровые подписи, манифесты и прочие плюшки jar — это все ни к месту здесь и из другой оперы.
> P.S. Сразу видно кто имел дело с java и их jar, а кто нет ;)
и это все ни к месту и указывает лишь на узкость вашего мышления. когда же люди научатся комментарии давать по существу?
Действительный итог: Архивом проще оперировать, чем деревом каталогов и файлов.
Все остальные плюшки реализуются не jar'ом, а инструментами. Jar = обычный zip архив.
Опять же, модули и плагины для CMS (выше писали). Тот же WordPress сам качает zip-архив и распаковывает его. А так — один файл, он качается, и он же работает. Выгода не столь очевидная, но свои плюсы, несоменно, имеются. Сама CMS может состоять из модулей (например, один архив — ядро, другой — шаблонизаторы и пр.), к тому же подписи — дополнительная защита от взлома и модификации файлов.
Offtopic: Перечитал комментарий с точки зрения «простого смертного». Много думал.
Было бы здорово включить в статью элементарное объяснение зачем это нужно. Кроме очевидного «один файл вместо кучи»
Это кстати решит проблемы с туевой кучей инклюдов для CMF типа Zend Framework. Никто не в курсе, кстати, есть ли zf-phar упакованный вариант?
Прикольно. Надо будет попробовать. Кстати там сказано что производительность ПОЧТИ не меняется без кэширования. И все же на сколько меняется?
Phar::ConvertToData(), который принимает три параметра: формат (Phar::TAR, Phar::ZIP), сжатие (Phar::NONE, Phar::GZ, Phar::BZ2) и расширение (.tar, .tar.bz2, .tar.gz, .zip).Вот это обстоятельство вызывает мои наибольшие опасения. Формат JAR, по крайней мере, всегда был переименованным ZIPом, так что от него было ясно, чего ждать. А тут получается, что пакет PHAR может даже иметь расширение .zip, но при этом внутренний формат сжатия — gzip
Может быть все-таки если выбран TAR, то учитывается второй параметр. Если выбран ZIP, то понятно, что второй параметр ни на что не влияет.
По-Вашему получается, что Phar::TAR и Phar::NONE даёт расширение .tar,
Phar::TAR и Phar::BZ2 даёт расширение .tar.bz2,
Phar::TAR и Phar::GZ даёт расширение .tar.gz,
Phar::ZIP даёт расширение .zip.
Однако тогда не очень понятно, чего им было городить огород с тремя параметрами. Достаточно было бы и одного — расширения.
Это беспокоит меня. Как бы не вышло так, что можно выбрать формат и сжатие одним способом, а расширение другим способом, и получить нечитаемый файл. Где защита от дурака?
Phar::TAR и Phar::BZ2 даёт расширение .tar.bz2,
Phar::TAR и Phar::GZ даёт расширение .tar.gz,
Phar::ZIP даёт расширение .zip.
Однако тогда не очень понятно, чего им было городить огород с тремя параметрами. Достаточно было бы и одного — расширения.
Это беспокоит меня. Как бы не вышло так, что можно выбрать формат и сжатие одним способом, а расширение другим способом, и получить нечитаемый файл. Где защита от дурака?
дает не расширение, а подрасширение.
ну, к примеру файл some.tar.phar или some.zip.phar
php5.kiev.ua/manual/phar.iscompressed.html
ну, к примеру файл some.tar.phar или some.zip.phar
Phar::isCompressed ( void )
Замечание: This method requires the php.ini setting phar.readonly to be set to 0 in order to work for Phar objects. Otherwise, a PharException will be thrown.
Returns Phar::GZ or PHAR::BZ2 if the entire phar archive is compressed (.tar.gz/tar.bz and so on). Zip-based phar archives cannot be compressed as a file, and so this method will always return FALSE if a zip-based archive is queried. php5.kiev.ua/manual/phar.iscompressed.html
UFO just landed and posted this here
UFO just landed and posted this here
Вот, ловите, если ещё нужно. ZF1 и ZF2 в Phar. Вчера испёк :)
Еще бы менеджер пакетов нормальный, а не убогий PEAR
pyrus, не?
Промахнулся. Это было ответом на habrahabr.ru/blogs/php/118269/#comment_3856886
include_once(‘some_archive.phar’);а что собственно происходит при таком вызове? Чисто вызов заглушки?
Да, а что-то еще нужно? В любом случае должен быть некий bootstrap, который и include_once сделает и создаст экземпляры нужных классов и вызовет какие нужно методы. ИМХО, в большинстве случаев, в заглушке самое то держать autoload для классов конкретного phar, который добавляется в цепочку других autoload. Это позволит в самом приложении оперировать самими классами абстрагируясь от того, где они физически находятся, в phar'e (каком либо из нескольких) или в простых приинклуженных php. А это ведет за собой еще одну выгоду: с минимальными изменениями кода можно будет развернуть такое (использующее phar) приложение на платформе со старым РНР, который не поддерживает phar, всего лишь распаковав всё содержимое архивов и переписав логику автолоадов.
Что не понял — так это зачем изобретать свой формат архива. Могли бы тот же tar использовать и какой-нить файлик манифеста. А так не имея под рукой PHP даже содержимого этого phar не посмотришь…
Ну, на ваше восклицание о том «зачем изобретать свой формат» есть строчки из документации:
Lastly, the Phar extension is security-conscious, and disables write access to executable phar archives by default, and requires system-level disabling of the phar.readonly php.ini setting in order to create or modify phar archives.
Лично я во всём этом вижу (поправьте меня если я не прав) шаг в сторону защиты авторских прав исключая использование дорогостоящих Zend Guard и прочих сопутствующих продуктов от Zend.
Lastly, the Phar extension is security-conscious, and disables write access to executable phar archives by default, and requires system-level disabling of the phar.readonly php.ini setting in order to create or modify phar archives.
Лично я во всём этом вижу (поправьте меня если я не прав) шаг в сторону защиты авторских прав исключая использование дорогостоящих Zend Guard и прочих сопутствующих продуктов от Zend.
Целая цмс сделанная в одном phar архиве http://mpak.su/ бонус — база данных sqlite лежит вместе с файлом цмс в одном директории
Sign up to leave a comment.
.phar — исполняемые PHP-архивы