Давай уж версию для совсем Ъ:
1) Что такое Composer?
2) Почему негодуют гентушники? Им же на ПХП должно быть насрать так же, как ПХПшникам на генту.
3) Почему ПХПшники против? Не пофиг ли ПХПшникам что там творят гентушники?

так а зачем их упаковывать. Фишка этих композеров же какраз в том чтобы ставить в обход системы.

1. Менеджер зависимостей для PHP

2. Они хотят паковать PHP проекты, но из-за Composer не могут этого сделать, т.к. он устанавливает зависимости локально для каждого проекта.

3. Гентушники предлагают вернуться им в прошлый век и заставить их использовать глобальные зависимости.

1) Что такое Composer?

Ты как маленький. НедоПМ для недоЯП.

2) Почему негодуют гентушники? Им же на ПХП должно быть насрать так же, как ПХПшникам на генту.

То есть какой-то кусок говнокода, возомнивший себя великим ПМ, хочет перепахивать ФС - и ты считаешь это нормальным?

3) Почему ПХПшники против? Не пофиг ли ПХПшникам что там творят гентушники?

У ПХПшников бомбит от того, что их поделие называют куском какахи, коим он и является. А в нормальные решения - ПХПшники не могут.

А зачем генте знать про то, что там делает этот композер?
Пусть пакуют сам композер и всё.
Ведь когда я пишу программу, создающую файлы, это ведь не вызывает нареканий со стороны гентушников? А композер, как я понял, просто создаёт файлы рядом с другим ПХПшным кодом.

То есть какой-то кусок говнокода, возомнивший себя великим ПМ, хочет перепахивать ФС - и ты считаешь это нормальным?

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

Потому что это сторонние библиотеки. А они хотят, чтобы все зависимости управлялись их пакетным менеджером.

Подробности там: https://wiki.gentoo.org/wiki/Project:PHP/The_Composer_problem

У питона сделано через жопу всё ставится глобально. Наверняка и у остальных что-то похожее.

Правильно делают. Пхпыхеры пусть на жабу уходят, Bioreactor`а потеснят немного.

Судя по последним событиям. Они быстрее PHP в жабу превратят.

Это точно. В своё время, когда на пыхпых кодил, всё не покидало стойкое ощущение того, что он стремительно бежит в сторону жабы. Они так скоро свою вм выкинут и полностью своё изделие пересадят на jvm. Так уж лучше сразу на жабу переучиться.

Man virtualenv

Это вряд-ли. Но есть сторонний проект: https://github.com/jphp-compiler/jphp

Нет, спасибо, меня пока buildout устраивает.

У Python'а всё через жопу

У питона сделано через жопу всё ставится глобально. Наверняка и у остальных что-то похожее.

Погодите-погодите, а всякие virtualenv'ы? Не один «адекватный» пейтонист (насколько они вообще могут быть адекватными) не ставит пакеты для разрабатываемого проекта в свою ОС, но для каждого проекта заводит отдельное окружение.

Я в курсе про virtualenv. Но я не понимаю, как этим вообще можно пользоваться?

А что не так? Все пользуются.

Не знаю. Возможно я один такой. Уж очень раздражает необходимость постоянно активировать/деактивировать окружение. Это пожалуй единственная причина. Именно поэтому я предпочитаю использовать buildout. Он так же, как composer например, генерирует файлы с прописанными путями к локальным зависимостям и всё. Не нужно совершать никаких лишних телодвижений.

В LFS'е таких проблем нет. Собирай что хочешь и как хочешь.

и да и нет, иной раз надо «ехать», а какая-нибудь программа требует с десяток экзотических зависимостей, и лень писать-тестировать билды, просто размазываешь файлы по системе ./configure && make && make install, но благо, пакетным менеджером потом любой мусор так же легко вычищается простым сравнием списка файлов БД ПМа и ФС.

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

мне в CRUX приходится вручную поддерживать 16 пакетов, и скажу, гемор тот ещё. потому что в репах их нет, или они собраны исключительно «абы-как». постоянно следить за новостями, обновлениями, секьюрити фиксами. брр.

ls /usr/ports/local/
bind/  exim/  hostapd/  libgsasl/  linux/      mcabber/  php-pgsql/   rfkill/
dhcp/  fvwm/  jabberd/  libidn/    loudmouth/  nginx/    postgresql/  udns/

PHP-проекты, которые перешли на Composer больше не могут быть упакованы в Gentoo

Чо правда? Ну наконец-то.

с одной стороны, как бы решение правильное, ибо это лишная работа упаковать код, если уже есть менеджер зависимостей компосер. Но это будет удобно, когда нет дополнительных зависимостей, к примеру от базы. Будет очень не удобно, когда zabbix придется ставить из composer, а далее вручную разворачивать базу, создавать вирт хосты и т.д. Поэтому для простых вариантов без сторонних зависимостей - можно отбросить пакетирование и использовать компосер, а сложные проекты - паковать.

Почему негодуют гентушники? Им же на ПХП должно быть насрать так же, как ПХПшникам на генту.

Дело в том, что могут быть какие-то веб-приложения, типа phpmyadmin, или там webmin какой-нибудь, которые ставятся через emerge и зависят от пых-библиотек, для которых теперь не будут делаться ebuild'ы, как я понял. Т.е. как-бы есть проблема.

Вот это боль. Богатый опыт с пхп, небось.

Будет очень не удобно, когда zabbix придется ставить из composer

Хм, но ведь с другой стороны, можно сделать ebuild который через composer установит zabbix и сделает всю настройку. Тем более что гента всё таки source-based и обычно пакеты собираются, почему бы не «собирать» через composer?

Никогда не понимал наличие вордпресса в репозиториях дистрибутива.

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

да, так будет более правильно

Их «проблема» в том, что они хотят тащить все библиотеки в свои репозитории, потому что так проще отслеживать security фиксы.

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

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

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

И кто они? Гентушники? В генту то как раз разные версии библиотек без проблем держать можно.

потому что так проще отслеживать security фиксы

Да и вообще с обновлением таких пакетов через emerge будет туго.

Кстати, а почему именно гентушники этим озаботились, разве в других дистрах этой проблемы нет, там не пакуют zabbix или phpmyadmin?

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

Ну вот допустим есть проект, который написан на laravel 4. Есть второй проект, который написан на laravel 5. А в системе к примеру может быть установлена только одна версия laravel. Кто идиот? Разработчики этих проектов, потому что не договорились использовать одну и ту же версию, или мейнтейнеры пакетов которые припёрлись в чужой монастырь со своими правилами?

Да, можно поставить два пакета, laravel4 и laravel5, но как они собираются заставить это работать? Если они не хотят использовать composer, то им тогда как ни крути придётся лепить свой велосипед.

Да, можно поставить два пакета, laravel4 и laravel5, но как они собираются заставить это работать?

https://wiki.gentoo.org/wiki/Webapp-config

разве в других дистрах этой проблемы нет

Не слышал ничего про это. В debian видел пхпшные пакеты, но я очень сомневаюсь, что этим кто-то вообще пользуется.

Ты пользовался гентой когда-нибудь?

В Генте спокойно можно держать и разные версии пакетов и разные версии библиотек и что хочешь.
Ты написал «один проект требует одну и ту же библиотеку разных версий» - вот это показатель того, что кодер невероятное школоло.

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

Не один «адекватный» пейтонист (насколько они вообще могут быть адекватными) не ставит пакеты для разрабатываемого проекта в свою ОС

Если проект один, то почему нет? Мне вот нафиг не сдался этот virtualenv, я спокойно всё ставлю средствами пакетного менеджера. Он для того и нужен, чтобы не плодить кучу виртуальных окружений и дубликатов библиотек.

Погодите-погодите, а всякие virtualenv'ы?

Каменный век. Сейчас модно сразу в docker заворачивать.

Ну так генту-разработчики готовы написать свой де-факто стандарт управления зависимостями, который не будет привязан к дистрибутиву взамен текущего очень популярного? Нет? Тогда скорее всего пойдут лесом.

В принципе, гентушники могли бы сделать свою реализацию composer'а, который вместо скачивания/прилинковывания зависимостей брал бы их из системы. Вполне взлетело бы, учитывая , что у portage самая вменяемая система обработки нескольких версий пакета, из всех что я видел. В разработке такой замены composer я бы, например, с радостью поучаствовал.

Ты написал «один проект требует одну и ту же библиотеку разных версий»

Нет.

когда разные пакеты требуют разные версии одной и той же библиотеки.

Под пакетом я подразумевал проект.

Я понимаю, что там можно держать что угодно. Проблема не в этом. Проблема в том, каким образом будет определяться то, какая версия библиотеки должна быть подключена. В php, чтобы подключить либы ты просто пишешь require 'path/to/file.php'. Файлов может быть неограниченное множество. Все эти файлы могут принадлежать одной библиотеке. А теперь представь, что библиотек используется более десятка и в каждой по куче файлов, которые надо зареквирить. Раньше с этим справлялся PEAR, но теперь его время прошло и ему на смену пришёл composer, а композер не позволяет устанавливать библиотеки глобально (вернее там есть возможность поставить пакет глобально, но это используется только для бинарных пакетов). И чтобы решить эту проблему, мейнтейнеры пакетов предлагают разрабам снова использовать глобальные зависимости.

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

Теперь оказывается глобальный зависмости прошлый век.

А PHP здесь при том, что ...

Не понимаю, что ты хотел этим сказать.

зареквирить

Пошёл за вилами.

Под пакетом я подразумевал проект.

Если ПРОЕКТ в стабильной версии, в финалке требует библиотеки разных версий - его создателей надо убить.

Если разные версии проекта требуют разные версии библиотек (старая - старую, новая - новую) - это ок.

О том, как работает composer ты можешь мне не рассказывать. Наоборот, что он наконец-то появился в php - это очень и очень хорошо. Для тех, кто еще вынужден с ним что-то писать.

Просто пришло время сделать очередной php-updater.

Уж очень раздражает необходимость постоянно активировать/деактивировать окружение.

Зочем? За тебя это делает ide, есть virtualenvwrapper который автоматически активирует env при переходе в директорию с проектом

Если ПРОЕКТ в стабильной версии, в финалке требует библиотеки разных версий - его создателей надо убить.

Об этом вообще речи не шло.

О том, как работает composer ты можешь мне не рассказывать.

Только от того, что в генте можно иметь несколько версий одного пакета это погоды не делает, если ты про это. Я попытался объяснить почему.

Я в саблайме и терминале сижу. Про virtualenvwrapper слышал, но про автоматическую активацию не знал. Если это действительно так, то очень даже хорошо. Но сама идея виртуальных окружений попахивает костылями, не так ли?

В других языках ведь почему-то додумались реализовать локальную установку зависимостей и только в питоне, насколько я знаю, приходится иметь для этого отдельный интерпретатор.

Возможно и костыли, спорить не буду(ибо лень). Для oh-my-zsh есть отличный плагин

не жаловался??

нет, погодите, это вы считаете на 'sudo pip install' и 'curl -sSL https://get.rvm.io | bash -s stable' никто не жаловался?