PHP: управление пакетами на прикладном уровне

Pear?

Есть очень сырая система модулей vqmod. Емнип он пока только умеет накатывать изменения, но не добавлять или удалять файлы.

Pear?

МегаЪ, что читаем только заголовок? :D

А нет ли готвого решения для работы с пакетами на уровне приложения?

Ну, скажем, в движке форума или CMS прямо из админки плагины ставить.

Что-то я сильно сомневаюсь, что кто-то был настолько крут, чтобы сделать пакетный менеджер на все случаи жизни. Каждое приложение/фреймворк - велосипед со своим типом не только колёс, но и всего остального.

но не хочется велосипедить

Не забудь прикрутить обработку зависимостей :)

Композер слишком легковесный для этого и банально туп. Тут надо что-то наподобие npm. Есть pear2. В общем можно локально делать репозитарии, но все равно слишком монструозно...

Мне попадалось несколько проектов, приближающихся к этой задаче. Надо вспомнить.

В идеале надо чтобы это был портаж как в генте и с оверлеями. Шучу.

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

Задача-то простая.

Не забудь прикрутить обработку зависимостей :)

Само собой, это первое, что нужно :)

В идеале надо чтобы это был портаж как в генте и с оверлеями. Шучу.

Да без шуток — вполне. Только намного проще, без всяких eclasses и ebuild'ы в духе композера. Только JSON не считаю удачным решением, лучше YAML :)

...

В общем, видимо, придётся велосипедить.

Да без шуток — вполне.

И это правильно. С маскировкой пакетов, USE-флагами, профилями и т.п. :))

Поддерживаю. Только YAML. JSON слабак по сравнению...

Главное, в таком менеджере - чтобы можно было публиковать изменения в up-stream с пол-пинка и рулить для разных версий не только пакетов, но и php-движков...

Вот что удалось вспомнить: https://github.com/lox/phark https://gist.github.com/711221

дискуссия на HN: http://news.ycombinator.com/item?id=3184170

еще одна дискуссия: http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php

Боюсь, что phark мёртв чуть более, чем полностью. И, как я понял, это именно самостоятельный пакетный менеджер а ля Composer (к нему в Phark и отсылают) или PEAR.

Мне же нужна минималистичная штука, чтобы эмбеддить её в готовые проекты и из них управлять компонентами этих проектов. Бэкендом под ней, как раз, хоть тот же Composer может быть. Типа, плагин публиковать на Packagist'е. Но вот загружать его — уже своим облегчённым вариантом. Эмбдеддить весь Composer в конечный проект — как-то излишне. Это если в нём вообще предусмотрен API для управления им из своих скриптов.

...

Думаю, нужно начинать с какой-то предельно минималистичнной штуки. Сперва тупо работа с файлами — регистрация/удаление. Распаковка во временную структуру (привет /var/tmp/portage) с копированием в систему и регистрацией в ней. Для начала в виде фиксированных архивов хотя бы. Потом можно подумать и про DVCS в варианте Composer'а. Кстати, интересно, он DVCS-репозитории утягивает по какому-то своему протоколу? Не обратил внимание при экспериментах, нужен ли ему локальный, скажем, mercurial, или он с packagist'а в каком-то своём формате (да хоть по одному файлу) тянет?

Боюсь, что phark мёртв чуть более, чем полностью.

Да, похоже на то. НО начиналось с него и там есть здравые идеи. Хотя в проекте есть сравнительно свежие коммиты.

Кстати, интересно, он DVCS-репозитории утягивает по какому-то своему протоколу? Не обратил внимание при экспериментах, нужен ли ему локальный, скажем, mercurial, или он с packagist'а в каком-то своём формате (да хоть по одному файлу) тянет?

Сейчас почти все PM работают по примерно такому принципу: в конфигах прописан тип VCS или url как в git (git://repo.site/path/to/ver.s.i.o.n) Далее пакетный менеджер разбирается какой интерфейс доступа к сорцам. Это как в идеологии генты - флаг-опция git-sources И это справделиво для случая, когда требуется дерево исходных кодов проекта. Если это не нужно (конечный пользователь и не разработчик) то уже тянутся тарболы (так-же как в генту) Неважно в общем какой протокол. Пакетный менеджер смотрит что ему подсовывают для вытягивания, в свою очередь смотрит так-же как это реализовать на локальной системе. Есть git - значит можно тянуть дерево кода. Нет гита, значит можно тянуть архивы. Есть поддержка phar, значит phar (не стоит заморачиваться на случаи когда его нет). Есть в системе wget значит будет транспорт по wget и т.д.

Нужен локальный

Здесь непонятно про что речь. Если ты про файл world, то у тебя в ~ будет такой файлик и не один а несколько: global|local Очень близка идеология npm в этом смысле...

Стоит обратить внимание, на то, как в генте работает ebuild для dev-db/phppgadmin Там раньше была возможность вытягивание 9999-версии по гит. Причем гит тянулся как bare-репозиторий. Интересная реализация.

...

Если хочешь обработку зависимостей, то важно определится что является единицей пакета. Далее можно уже рулить зависимостями. Для углубленного вдохновения: emerge, новый пакетный менеджер freebsd

Для простой реализации нужно:

• world
• очень простой парсер CLI
• и собственно ПМ

Этого достаточно для реализации простого варианта велосипеда: установить файл, удалить файл, показать что установлено

http://getcomposer.org/

Ctrl-F «композ»