Composer будь он неладен ...

[hell0w0rd]

scorpion-ds, есть мнение, что в проекте стоит хранить не только composer.lock, но и vendor. Тогда зависимость от packagist уменьшается. Ровно то же действует для npm, bower и прочих пакетных менеджеров.
Или как выше правильно написали - запускать свой инстанс satis, или packagist и кешировать к него версии.

 

[флоппик]

scorpion-ds, есть мнение, что в проекте стоит хранить не только composer.lock, но и vendor. Тогда зависимость от packagist уменьшается. Ровно то же действует для npm, bower и прочих пакетных менеджеров.

Точно! А лучше сразу образ виртуалки тиражировать между разработчиками. И в гит его ложить.

 

[hell0w0rd]

https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md - ну вот тут написано, что не стоит, действительно. Однако есть инструкция, как делать это правильно, если таки нужно.

 

[scorpion-ds]

scorpion-ds, есть мнение, что в проекте стоит хранить не только composer.lock, но и vendor. Тогда зависимость от packagist уменьшается. Ровно то же действует для npm, bower и прочих пакетных менеджеров.
Или как выше правильно написали - запускать свой инстанс satis, или packagist и кешировать к него версии.

vendor - может быть очень большим,что там меня не должно интересовать и не имеет по особой ценности, это как если предавать кому-то игру "Косынка" и вместе с ней образ с виндой. ИМХО

Хотя к примеру проекты на CMS я храню в репозиториях полностью.

 

[hell0w0rd]

scorpion-ds, эм, нет. Это если ты будешь передавать косынку, а вместе с ней статически слинкованную sdl, на пример.

 

[grigori]

Очень большой - это сколько? до 100 мегабайт - это не много. Git сжимает при сохранении, а передает только изменения. Репозиторий с дампом на пару сотен метров мы юзали без проблем.

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

Делать свое зеркало репозитория пакетов OS тоже хорошо.

 

[Absinthe]

и как все до композера обновляли библиотеки?

А какого качества код был в те времена?
Можно просто посмотреть на говнокод wordpress и обильно проблеваться.

Прогресс пришел к PHP. Теперь у нас есть github, composer и PSR.

Кому-то надо напомнить, как роскомнадзор забанил гитхаб?…

Тут скорее надо думать, не как действия этих уродов обойти, а как предотвратить их в дальнейшем.
Решения два: иммиграция или появление гражданского общества.

 

[grigori]

Теперь у нас есть github, composer и PSR

Как же вы любите софизмы. Я просто фигею как народ пишет ложь. Репозиторию и менеджеру пакетов в PHP 15 лет.
Гитхабу - 7 лет. 5 лет назад приняли PSR. Теперь мы можем ими пользоваться. Спасибо за разрешение

 

[hell0w0rd]

Absinthe, git submodules придумали еще до гитхаба. composer - это git submodules с кешом в виде packagist и резолвингом semver, вместо хешей коммитов.
https://events.yandex.ru/lib/talks/1936/ - вроде в этом докладе упомянули о том, что команда яндекс почты(или другая) за собой таскает аж нужную версию gcc, чтобы код точно работал.

 

[Absinthe]

Как же вы любите софизмы. Я просто фигею как народ пишет ложь. Репозиторию и менеджеру пакетов в PHP 15 лет.
Гитхабу - 7 лет. 5 лет назад приняли PSR. Теперь мы можем ими пользоваться. Спасибо за разрешение

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

 

[AmdY]

Думаю речь идёт о SVN и PEAR, там и стили кодирования и стандартный автолод продумали, было всё тоже самое, только ещё во времена php 4 и с опоркой на BC. На самом деле, даже активно двигающееся meedleware это наследие фреймворка seagull.

 

[Absinthe]

Думаю речь идёт о SVN и PEAR, там и стили кодирования и стандартный автолод продумали, было всё тоже самое, только ещё во времена php 4 и с опоркой на BC. На самом деле, даже активно двигающееся meedleware это наследие фреймворка seagull.

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

 

[AmdY]

Absinthe, "это не проблема ООП" © HraKK

 

[Sad Spirit]

И только это никто не использовал.

Использовали, потом перестали. И тут надо передать горячий привет долбо@#ам из фирмы Zend, которые угробили PEAR своими политическими решениями времён Zend Framework 1.
* Вместо того, чтобы развивать классы PEAR и портировать их на PHP5, они начали писать всё своё и с нуля, да ещё и лицензионный FUD развернули.
* Вместо того, чтобы использовать (и дорабатывать) существующий пакетный менеджер, своё поделие они раздавали одним куском. Ибо нехрен быдлу выбирать, что использовать, а что нет.

Во многом благодаря Zend'у было тупо прогажено несколько лет, до появления компостера и прочего гитхаба. Ну и тут пришло новое поколение, которое считает, что само всё придумало, а до этого была ледяная пустыня, да.

 

[Absinthe]

Sad Spirit, почему все на ZF ориентируются? Ничем не примечательный фреймворк посредственного качества.

 

[AnrDaemon]

Absinthe, ссылаются, а не ориентируются…

 

[fixxxer]

Sad Spirit, ну да. Когда композер только появился, я сильно негодовал, какого черта вместо PEAR свой велосипед. Со временем, как PEAR окончательно сдох, претензия неактуальна стала, ага.

 

[grigori]

http://www.bbc.co.uk/russian/rolling_news/2015/03/150326_rn_netherlands_power_cut

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

 

[AmdY]

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

 

[Absinthe]

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

Зачем так брутально сразу? Просто надо иметь локальный пакажист у себя.