LINUX.ORG.RU
ФорумTalks

Шок! Гентушники хотят отправить пхпшников в прошлый век!

 , ,


1

1

!Ъ: http://www.garfieldtech.com/blog/composer-distribution-mental-model

Ъ: PHP-проекты, которые перешли на Composer больше не могут быть упакованы в Gentoo. Гентушники негодуют, а пхпшники против того, чтобы принять их «хорошие» решения проблемы.

★★★★★

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

Stahl ★★☆ ()

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

Bad_ptr ★★★★ ()
Ответ на: комментарий от Stahl

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

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

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

Kilte ★★★★★ ()
Последнее исправление: Kilte (всего исправлений: 1)
Ответ на: комментарий от Stahl

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

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

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

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

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

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

ekzotech ★★★★ ()
Ответ на: комментарий от Kilte

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

Stahl ★★☆ ()
Последнее исправление: Stahl (всего исправлений: 1)
Ответ на: комментарий от ekzotech

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

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

Deleted ()
Ответ на: комментарий от Kilte

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

Hertz ★★★★★ ()
Ответ на: комментарий от Kilte

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

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

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

Camel ★★★★★ ()
Ответ на: комментарий от pawnhearts

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

Kilte ★★★★★ ()
Ответ на: комментарий от saahriktu

и да и нет, иной раз надо «ехать», а какая-нибудь программа требует с десяток экзотических зависимостей, и лень писать-тестировать билды, просто размазываешь файлы по системе ./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/
Spoofing ★★★★★ ()

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

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

no-such-file ★★★★★ ()

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

kiotoze ★★★★ ()
Ответ на: комментарий от Stahl

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

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от ekzotech

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

Deleted ()
Ответ на: комментарий от kiotoze

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

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

no-such-file ★★★★★ ()

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

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от no-such-file

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

Kilte ★★★★★ ()

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

Kilte ★★★★★ ()
Ответ на: комментарий от Kilte

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

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

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

tazhate ★★★★★ ()
Ответ на: комментарий от Kilte

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

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

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от tazhate

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

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

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

Kilte ★★★★★ ()
Ответ на: комментарий от no-such-file

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

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

Kilte ★★★★★ ()
Ответ на: комментарий от Kilte

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

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

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

tazhate ★★★★★ ()
Ответ на: У Python'а всё через жопу от Camel

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

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

vurdalak ★★★★★ ()
Ответ на: комментарий от tazhate

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

Deleted ()

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

Sectoid ★★★★★ ()
Ответ на: комментарий от tazhate

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

Нет.

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

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

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

Kilte ★★★★★ ()
Ответ на: комментарий от Kilte

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

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

swelf ()
Ответ на: комментарий от swelf

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

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

Kilte ★★★★★ ()
Ответ на: комментарий от Kilte

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

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

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

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

tazhate ★★★★★ ()

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

Suigintou ★★★★ ()
Ответ на: комментарий от Kilte

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

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

ggrn ★★★★★ ()
Ответ на: комментарий от tazhate

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

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

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

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

Kilte ★★★★★ ()
Ответ на: комментарий от ggrn

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

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

Kilte ★★★★★ ()
Последнее исправление: Kilte (всего исправлений: 1)
Ответ на: комментарий от Kilte

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

ggrn ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

alpha ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.