Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
И все в этом сообществе так: написали composer (композитор), а нарисовали director (дирижер).
А ведь правильно человек заметил, за что минусуем?
Да, определенная нестыковочка имеется: еще и домена разных 2 — getcomposer и packagist, причем ни один из них не совпадает с названием утилиты. Нейминг получился перегруженный слегка, хотя сама утилита хороша.
Ну, если прочитать статью, то становиться ясно, что getcomposer.org — это сайт, откуда можно скачать саму утилиту, а packagist.org — это официальный репозиторий Composer пакетов.
Может быть ещё и слон (elephpant) на самом деле это не слон, а редкий черный бегемот? Мне очень нравится фраза, которую я от кого-то услышал: «когда кончаются аргументы, начинают переходить на личности».
бандлер — одна из лучших вещей, что есть в экосистеме руби. большой прогресс, что подобное пришло и в пхп.
только портянки json конфигов как-то не очень, с DSL читалось и редактировалось бы гораздо проще
как-то так по аналогии с gemfile из руби:
только портянки json конфигов как-то не очень, с DSL читалось и редактировалось бы гораздо проще
как-то так по аналогии с gemfile из руби:
packet 'silex'
packet 'twig', ">=1.8,<2.0-dev",
packet 'superlogger', git: 'git://github.com/pqr/superlogger'
packet 'superlib', git: 'git://github.com/pqr/superlib', tag: 'v1.2.3', autoload: 'timer'
packet 'smarty', svn: 'http://smarty-php.googlecode.com/svn/', branch: 'Smarty_3_1_7'
При попытке выполнить php composer.phar install получаю сообщение об ошибке:
Problems: — The requested package mycompany/superlogger == 9999999-dev could not be found.
PHP 5.3.13 / Win7
Problems: — The requested package mycompany/superlogger == 9999999-dev could not be found.
PHP 5.3.13 / Win7
Вы использовали Mercurial или git версию? Попробуйте запустить php composer.phar -v install
git. Параметр -v не помог. Помогла установка date.timezone, до этого он ругался, что не установлено дефолтное значение и упорно игнорировал master-бранч (Reading composer.json of github.com/pqr/superlogger (master)Skipped branch master)
> Что умеет Composer?
А где интеграция с PEAR-ом? Она же вроде бы есть?
> «Потому что. Просто примите это.»
Какой-то json головного мозга… Лучше бы минут за 20 накидали XML схему и получили в качестве бонусов легкость написания конфигов (все нормальные XML редакторы отлично работают со схемами) и простоту их проверки в софте.
А где интеграция с PEAR-ом? Она же вроде бы есть?
> «Потому что. Просто примите это.»
Какой-то json головного мозга… Лучше бы минут за 20 накидали XML схему и получили в качестве бонусов легкость написания конфигов (все нормальные XML редакторы отлично работают со схемами) и простоту их проверки в софте.
Это у вас XML головного мозга. Если ваш IDE убирает все изначальное неудобство и нечитаемость XML, это не значит что XML резко становиться лучшим форматом для конфигов. Это лишь значит, что ваш IDE убирает все изначальное неудобство и нечитаемость XML (отжирая на это сотни мегабайт оперативы?).
JSON не идеальный формат. Изначально был разговор с Жорди и о yml и о DSL на чистом PHP, но ребята решили пойти по пути npm. И оно работает!
XML? Bitch, please:
github.com/symfony/symfony1/blob/1.4/data/bin/release.php
JSON не идеальный формат. Изначально был разговор с Жорди и о yml и о DSL на чистом PHP, но ребята решили пойти по пути npm. И оно работает!
XML? Bitch, please:
github.com/symfony/symfony1/blob/1.4/data/bin/release.php
Полностью поддерживаю. Это через уже совсем дурдом, если для правки конфигов придется IDE стартовать
Насчет «сотен мегабайт оператива» — бред (а тот небольшой оверхед который будет — совсем не критичен для инструмента разработки). Если вам удобно постоянно смотреть документацию, а без этого написать конфиг невозможно и нравится постоянно писать велосипеды для проверки структуры этих файлов — удачи. Я же предпочту переложить это на используемый инструмент.
> XML? Bitch, please:
И к чему это?
И к чему это?
Это к тому, что XML никогда в качестве формата конфигурации/описания пакетов не работал. Смотрим на PEAR — каждый крупный проект писал скрипт для билда xml описания пакета. Скрипт, который генерировал описание пакета, который использовался для создания пакета. И так делали все проекты с мало-мальски крупной базой кода.
Оно просто никогда не работало. Если вам кажется обратное, значит вы просто никогда серьезно этим не пользовались.
Оно просто никогда не работало. Если вам кажется обратное, значит вы просто никогда серьезно этим не пользовались.
В джаве вполне успешно работает, в maven. Имхо, json в плане читабельности ненамного лучше, а автокомплит часто помогает.
Речь про PHP. JAVA — отдельная история. Неоднократно слышал от джавистов что на джава писать без IDE невозможно. В виду этого, для джавы XML действительно может быть идеальным форматом для всего :) Ибо IDE, которая для многих (всех?) джавистов обязательна, будет автоматически компенсировать огрехи формата.
И для php и для джавы пользуюсь ide, так что не буду особо спорить. Просто любопытно, в каком популярном программерском редакторе проблемы с редактированием xml?
> Неоднократно слышал от джавистов что на джава писать без IDE невозможно.
Совсем по другой причине — API (как и сами проекты) гораздо больше и сложнее, запомнить все невозможно. Впрочем, ни один большой проект на PHP тоже невозможно полноценно разрабатывать без современной IDE.
Совсем по другой причине — API (как и сами проекты) гораздо больше и сложнее, запомнить все невозможно. Впрочем, ни один большой проект на PHP тоже невозможно полноценно разрабатывать без современной IDE.
> ни один большой проект на PHP тоже невозможно полноценно разрабатывать без современной IDE
Занимаюсь разработкой 2ух (Behat, Mink) и активным контрибутом в другой десяток очень крупных проектов (Symfony2, Composer, Doctrine2) на PHP через vim. Другие аргументы?
Занимаюсь разработкой 2ух (Behat, Mink) и активным контрибутом в другой десяток очень крупных проектов (Symfony2, Composer, Doctrine2) на PHP через vim. Другие аргументы?
> Это к тому, что XML никогда в качестве формата конфигурации/описания пакетов не работал.
ivy (http://ant.apache.org/ivy/), maven (http://maven.apache.org/) и др. проекты с вами не согласны.
> Смотрим на PEAR — каждый крупный проект писал скрипт для билда xml описания пакета
Для генерации XML файлов, есть XMLWriter (http://ru2.php.net/XMLWriter), который довольно сильно это упрощает (особенно если добавить пару методов для добавления массивов элементов и атрибутов).
Насчет конфигов — нужно различать данные, которые предназначены для редактирования пользователем (описание пакета и зависимостей) и служебные данные (список того что установлено, откуда уставлено и т.д.).
Для второго типа данных можно использовать любой формат, т.к. никто кроме программы (и в редких случаях её разработчика) эти файлы читать не будет. Можно даже, отказать от их проверки в программе (если кто-то криворукий догадается их «поправить» — это его проблемы).
А вот со вторым приходится работать обычным пользователям => необходима проверка этого файла (велосипед) и вот в этом случае XML схема отличнейший вариант, причины см. в моем первом комментарии (http://habrahabr.ru/post/145946/#comment_4910138) (намекну – вся проверка сведется к вызову «DOMDocument::schemaValidate»)
> DSL на чистом PHP
Тоже, кстати, неплохой вариант, и будет работать даже если нет поддержки XML (это можно было привести в качестве более реального недостатка XML), и так же как и схема упростил бы написание конфигов (автокомплит) и избавил бы от необходимости смотреть в документацию (phpdoc). Правда сваять на коленке нормальный DSL уже не получится.
ivy (http://ant.apache.org/ivy/), maven (http://maven.apache.org/) и др. проекты с вами не согласны.
> Смотрим на PEAR — каждый крупный проект писал скрипт для билда xml описания пакета
Для генерации XML файлов, есть XMLWriter (http://ru2.php.net/XMLWriter), который довольно сильно это упрощает (особенно если добавить пару методов для добавления массивов элементов и атрибутов).
Насчет конфигов — нужно различать данные, которые предназначены для редактирования пользователем (описание пакета и зависимостей) и служебные данные (список того что установлено, откуда уставлено и т.д.).
Для второго типа данных можно использовать любой формат, т.к. никто кроме программы (и в редких случаях её разработчика) эти файлы читать не будет. Можно даже, отказать от их проверки в программе (если кто-то криворукий догадается их «поправить» — это его проблемы).
А вот со вторым приходится работать обычным пользователям => необходима проверка этого файла (велосипед) и вот в этом случае XML схема отличнейший вариант, причины см. в моем первом комментарии (http://habrahabr.ru/post/145946/#comment_4910138) (намекну – вся проверка сведется к вызову «DOMDocument::schemaValidate»)
> DSL на чистом PHP
Тоже, кстати, неплохой вариант, и будет работать даже если нет поддержки XML (это можно было привести в качестве более реального недостатка XML), и так же как и схема упростил бы написание конфигов (автокомплит) и избавил бы от необходимости смотреть в документацию (phpdoc). Правда сваять на коленке нормальный DSL уже не получится.
Про джава проекты смотрим коммент выше.
Про разделение данных, конечно можно использовать десятки программ, которые в совокупности возможно сделают редактирование пакетной конфигурации проще, а можно просто отредактировать *.json файл в vim/textmate/notepad/sublime/anything_else.
Про DSL на PHP — как вы будете разбирать такие описания пакетов на центральном сервере (packagist?) не рискуя безопасностью? Почитайте мэйл-листы ребят с rubygems чтобы понять всю суть проблемы.
Про разделение данных, конечно можно использовать десятки программ, которые в совокупности возможно сделают редактирование пакетной конфигурации проще, а можно просто отредактировать *.json файл в vim/textmate/notepad/sublime/anything_else.
Про DSL на PHP — как вы будете разбирать такие описания пакетов на центральном сервере (packagist?) не рискуя безопасностью? Почитайте мэйл-листы ребят с rubygems чтобы понять всю суть проблемы.
> в vim/textmate/notepad/sublime/anything_else
А XML нельзя, да? :)
> Про DSL на PHP — как вы будете разбирать такие описания пакетов на центральном сервере (packagist?) не рискуя безопасностью?
Ключевое тут DSL, а значит очень узкая область применения, и, как следствие, совсем небольшой набор синтаксических конструкций => можно через tokenizer проверить чтобы присутствовали только разрешенные методы (если реализация DSL будет через методы, что, опять же, логично из-за автокомплита). Или же, может быть, можно использовать песочницу из runkit-а (не пробовал).
А XML нельзя, да? :)
> Про DSL на PHP — как вы будете разбирать такие описания пакетов на центральном сервере (packagist?) не рискуя безопасностью?
Ключевое тут DSL, а значит очень узкая область применения, и, как следствие, совсем небольшой набор синтаксических конструкций => можно через tokenizer проверить чтобы присутствовали только разрешенные методы (если реализация DSL будет через методы, что, опять же, логично из-за автокомплита). Или же, может быть, можно использовать песочницу из runkit-а (не пробовал).
Посмотрите немного шире — XML это целая куча технологий, например, то же описание пакетов в статичном HTML можно было бы генерировать с помощью XSLT (про документацию к схеме я молчу). Но зачем? Правильно, лучше json и еще пару велосипедов.
Спор XML vs JSON/YAML/ini/… по-моему сроден спору «Windows-way» vs Unix-way. Нужен ли нам мощный формат, который способен нормально выполнять 100500 функций или для каждой функции нужен формат, который её выполняет хорошо. Для больших проектов наверное XML оправдан как единый язык, просто потому что он будет единым и для конфигов, и для экспорта/импорта, и для удаленного взаимодействия и для хранения данных даже. Но если нам нужно просто хранить с десяток настроек, да ещё который будет редактироваться не сильно продвинутым пользователем, то оправдано ли составлять для них DTD или XSD?
> который будет редактироваться не сильно продвинутым пользователем
У вас «хорошее» мнение о большинстве PHP разработчиков :)
> IDE и автокомплит вещи не связанные.
IDE там не просто так в кавычки взято.
ЗЫ: Печальная дискуссия получилось, почему адепты json-а молчат про «json schema»? Я вот, например, только что о ней узнал (что неудивительно в виду её малой распространенности), а она как раз и является альтернативой XML схемам (но её поддержка опять же гораздо меньше).
У вас «хорошее» мнение о большинстве PHP разработчиков :)
> IDE и автокомплит вещи не связанные.
IDE там не просто так в кавычки взято.
ЗЫ: Печальная дискуссия получилось, почему адепты json-а молчат про «json schema»? Я вот, например, только что о ней узнал (что неудивительно в виду её малой распространенности), а она как раз и является альтернативой XML схемам (но её поддержка опять же гораздо меньше).
К счастью, у них хотя бы не XML головного мозга.
Играюсь с компосером, подключаю Slim пакетом, путь к нему улыбнул:
project/vendor/slim/slim/Slim/Slim.php ))
Ребят, объясните, а лучше покажите пример, как правильно загружать js файлы (или копировать в папку проекта), которые были установлены как пакет через composer в папку vendor?
Можно использовать плагин типа такого, www.phpclasses.org/blog/package/8429/post/1-Using-Composer-to-Install-JavaScript-CSS-and-Images-Under-the-Web-Document-Directory.html
Либо грузить всё в vendor и делать симлинки в вебрут для js/css/бутстрапов.
Либо грузить всё в vendor и делать симлинки в вебрут для js/css/бутстрапов.
Пасиба за прекрасную вводную статью!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Composer — менеджер зависимостей для PHP