 |
 |
У нас давеча сложилась очень интересная и горячая дискуссия с коллегами по поводу использования Composer-а в проектах, над которыми мы работаем. Очень бы хотелось услышать мнение «широкой общественности» по этому вопросу.
Камнем преткновения стал очень простой вопрос:
Стоит ли хранить содержимое папки vendor в наших репозиториях?
Как Вы, в общем наверняка уже догадались, мнения разделились:
ДА
Это часть нашего приложения, за которое мы несем ответственность и все зависимоасти должны храниться в одном месте. В данном случае имеетс в виду, что без сторонних библиотек наш код теряет функциональность.Контр-аргумент: в таком случае, нам надо еще завести в свой репозиторий используемые пакеты уровня операционной системы (apt-get, например). Ведь при использовании аналогичного инструмента в Java — Maven, например, никто же не хранит сторонние зависимости, а только описание оных. Сюда же можно отнести npm, pip и прочие.
НЕТ
Это 3-rd party библиотеки, которые мы просто используем. Желаемого эффекта «неизменности» можно достичь жесткой фиксацией версии библиотеки в composer.json.Контр-аргумент: отсутствие контроля над разработкой стороннего кода. В случае закрытия или «плохого кода» в проекте вендора, мы теряем функциональность.
Для полноты картины, пройдите, пожалуйста, небольшой опрос.
Ссылки:
- Composer — getcomposer.org
- Apache Maven — ru.wikipedia.org/wiki/Apache_Maven
UPDATE 1
В качестве зависимостей в данном случае имеются в виду официальные SDK для сторонних API, например, или инструменты автоматизации. Т.е. данные пакеты не могут исчезнуть за 1 день.
UPDATE 2
Обсуждение подразумевает хранение вендорского кода ни на прокси для packagist, ни в отдельных форках, а прямо в репозитории с проектом.
UPDATE 3
Под проектом подразумевается некое web-приложение или сервис, но не библиотека, разрабатываемая компанией.
UPDATE 4
В проекте есть и активно используется build для сборки js/css файлов. Это важно, потому что в этот процесс (по мнению автора) должна быть включена сборка php зависимостей.
UPDATE 5
Вышеупомянутые build-ы запускаются на тестовом окружении (или специальном build-сервере) и выкатываются на боевые сервера уже в готовом виде. Это значит что ситуация с разными версиями пакетов между test/stage/live в принципе не возможна.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (139)
galk_in
15.10.2015 20:06+11Изменения в vendor не должно быть. Иначе делайте свой репозиторий и его реквариуем.
Храним composer.lock При деплои используем composer install. Так мы гарантируем идентичность. Любой composer update это мердж.
zenn
15.10.2015 22:56Тоже согласен, в случае, если нет уверенности в «успешной и долгой» жизни используемого пакета в vendor или у вас достаточно сильно выражена паранойя можно попросту сделать его форк (что благодаря github делается в полтора клика). Да, это все же будет отнимать определенное время на обслуживание сторонней библиотеки(мержи и т д) но вы будете уверены в том, что до тех пор, пока вам необходим данный пакет он будет доступен.
Плюс, если у вас имеется механизм «релиза» (аналогичный github) можно прикреплять «скомпилированные» версии вашего продукта с включенной папкой vendor на дату релиза.
fog
15.10.2015 20:13-9Я случайно проголосовал за «Не стоит» но на самом деле я считаю что стоит и в своих проектах так и делаю.
Основная причина, потому что когда в репозитории переключаешься с ноды на ноду, с ветки на ветку — уходит очень много времени чтобы выполнить `composer update`, а когда код в репозитории — это делается моментально. Почему бы НЕ хранить библиотеки в репозиториии — я не вижу, размер меня не беспокоит, 40MB (в моём случае) не такой существенный размер, можен быть и намного больше.
Вторая причина, когда делаешь diff двух веток (в меркуриале, TortoiseHg просто выделаешь две ноды и выбираешь «Visual Diff», при этом у меня открывается Araxis Merge) можно быстро посмотреть не только дифф своего кода но и библиотек, если они изменились.fog
15.10.2015 20:15Ну и ещё один маленький плюс, если у вас деплой происходит из системы контроля версий, опять таки, из неё всё достаётся быстрее, чем достать код из репозитория + сделать достаточно долгий composer install.
Blumfontein
15.10.2015 20:19+8Зачем вы делаете composer update, когда надо делать composer install? При наличии lock-файла и всех вендоров в кэше composer install в интернет не ходит и ставит все мгновенно.
fog
15.10.2015 20:46-5Если версии библиотек в composer.json изменились и вы делаете install то получаете такое сообщение
composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. *Run update* to update them.
Nothing to install or update
Generating autoload files
Так что нужно делать именно «composer update»Blumfontein
15.10.2015 21:01+5Это значит, что произошел рассинхрон между composer.json и composer.lock, и тому, кто в таком виде закоммитил код, надо крепко по рукам надавать.
fog
15.10.2015 21:35-4Да, действительно, вы правы, если lock соответствует composer.json, то изменение версий происходит быстрее, не момнетально но существенно быстрее, чтобы в общем-то этот пункт снять.
Но в остальном, в принципе, узнав это я врядли удалю vendor из репозитория, потому что я по сути всё ещё не вижу в этом недостатков, а плюсы всё ещё есть:
- Всё таки свитч чуть быстрее
- Не нужно настраивать хуки чтобы они делали composer install
- Как я уже говорил, можно быстро посмотреть дифф библиотек и увидеть полную картину изменений от версии к версии
- Всё таки деплой быстрее, так как кешей в чистом контейнере нет и там нужно делать install
- Плюс когда делаешь install теоретически могут быть проблемы с репозиториями, всё таки они не 100% времени доступны, в России бывали случаи и блокировки GitHub'a.
- Кто знает, что прийдёт в голову разработчику того или иного пакета, вдпруг он решит удалить свой репозиторий. Такая версоятость мала, но тоже не стоит совсем её исключать.
Corpsee
16.10.2015 05:08+1Последние 2 пункта можно решить с помощью Satis. Он проксирует запросы на Packegist и умеет сохранять пакеты у себя.
Fesor
17.10.2015 14:21+1Всё таки свитч чуть быстрее
как мы уже выяснили .lock файлы решают это проблему чуть более чем полностью, а работать сразу дан несколькими фичами, которые к тому же требуют разные зависимости, это признак проблем в процессе разработки.
Не нужно настраивать хуки чтобы они делали composer install
я их и не настраиваю и не коммичусь. Повторюсь, это довольно редкий кейс когда у нас по веткам разбросаны разные версии пакетов.
Как я уже говорил, можно быстро посмотреть дифф библиотек и увидеть полную картину изменений от версии к версии
Это можно сделать просто через git, на github например или склонив интересующий нас репозиторий и сделав git diff v1.0.1 v.1.0.2 например. В целом я предпочитаю вообще не париться об этом и использовать библиотеки соблюдающие семвер.
Всё таки деплой быстрее, так как кешей в чистом контейнере нет и там нужно делать install
У меня вендоры имеются в билде (tar.gz, deb, docker образ, etc) который деплоится. Но это не повод ложить это добро в git. Для ускорения сборки можно юзать satis или коммерческий вариант — toran proxy.
Плюс когда делаешь install теоретически могут быть проблемы с репозиториями
кэш, statis, toran proxy.
Кто знает, что прийдёт в голову разработчику того или иного пакета, вдпруг он решит удалить свой репозиторий.
Это риск работы с любым сторонним пакетом. Как правило это либо бесполезный шлак либо можно сделать зеркало на гитхабах.
fog
15.10.2015 21:43Вот внизу тоже оставили ссылу на подобную тему, про npm habrahabr.ru/post/185200
Я с её автором в принципе согласен. К стати, иронично, что в проектах по работе, где у нас используется node/npm — мы не храним депенденси в репозитории :)
Blumfontein
15.10.2015 20:13+10«Желаемого эффекта «неизменности» можно достичь жесткой фиксацией версии библиотеки в composer.json.»
Для этого придумали composer.lock
Delphinum
15.10.2015 20:35+3Это часть нашего приложения, за которое мы несем ответственность
Вы не несете ответственность за сторонние библиотеки, даже если зависите от них.
отсутствие контроля над разработкой стороннего кода. В случае закрытия или «плохого кода» в проекте вендора, мы теряем функциональность
Если вы этого боитесь, пойдите по пути Microsoft и пишите все с нуля «заимствуя» (или покупая) идеи у сторонних разработчиков.
vintage
15.10.2015 20:45+2Я просто оставлю это здесь :-)
http://habrahabr.ru/post/185200/
delicious
15.10.2015 22:37Я просто добавлю это между двумя «просто оставлю это здесь».
getcomposer: The general recommendation is no.
maximw
15.10.2015 23:56-2Источник, конечно, авторитетный. Очень даже.
Но вот аргументы там сводятся к единственному «зачем вам лишнее место занимать, да историю репы засорять». Как-то не убедительно.Delphinum
16.10.2015 00:21+2Ну не знаю, если у вас репа = помойка, то аргументы и правда не убедительные.
m00t
16.10.2015 17:54Это устаревшая инфа. Вот новая: docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git
evnuh
15.10.2015 20:47Я просто оставлю это здесь :-)
toster.ru
t1gor
15.10.2015 22:04Мне не хватило доводов в пользу отказа от хранения вендорского кода локально, именно по этому я написал сюда, а не на тостер. Мне нужны аргументы за и против + статистика по опросу. По-моему Хабр для этого и создан, разве нет?
Delphinum
15.10.2015 22:06Хабр создан для того, чтобы люди могли делиться информацией с другими людьми. Тостер создан, чтобы люди могли вопрошать у других людей. Чувствуете разницу? )
dim_s
15.10.2015 21:16+1Надо хранить, потому что Maven практически на 100% гарантирует, что зависимость никто не удалит из рапозитория, а композер часто завязан на левые git репозитории, которые могут удалить авторы библиотек, к тому же у Maven более серьезные требования к зависимостям.
t1gor
15.10.2015 22:13Ну это скорее вопрос выбора библиотек, получается. Понятно, что не нужно тянуть в проект все, что «подходит по теме». В данном случае имеются в виду официальные SDK для сторонних API, например, или инструменты автоматизации.
garex
15.10.2015 21:18+1Никогда не стоит. Для этого сделан composer.lock
Даже если идет модификация внешних либ, то это делается в отдельных форках (пусть и приватных) и при деплое собирается максимум из кэша.
Хранить вендоров в репо — это верх сказочности )) Те кто это предлагал, не сторонники ли того товарища, который верит в то, что скоро программисты не нужны и компьютер будет писать код?
Lisio
15.10.2015 21:39+1Давайте представим ситуацию: боевой сервер сгорел, в бэкапах вендоры не хранятся, автор свой репозиторий удалил. Какие действия?
garex
15.10.2015 21:45+3У любого девелопера есть на машинке точная копия вендоров по composer.lock'у
Даже если гитхаб взорвется, прелесть гита в том, что ему не нужен центральный сервер.
Использовать ненадежные либы в проекте тоже странно. Короче бежать надо с такой организации, где люди основ пакетирования не внемлют (будь то композер, нпм или еще что).VolCh
16.10.2015 11:59Точная копия на конкретную версию composer.lock, не факт, что на ту, что была на боевом сервере.
garex
16.10.2015 12:23Вообще-то факт. Конечно при условии что при деплое на бою не забыли нажать `composer install`.
composer.lock при любом изменении (обновление коммита в либе или версии) себя самоподписывает.VolCh
16.10.2015 14:25Боевой сервер умер с зависимостью от пакета X, а девелоперы работали с веткой в которой этой зависимости уже нет.
t1gor
16.10.2015 14:31На боевом сервере никто билды ранить не будет, туда переносится уже готовый и протестированный пакетс test/stage. Так что эта проблема не рассматривается в контексте данного обсуждения.
Delphinum
15.10.2015 21:50Вы забыли еще добавить к этой картине: вой волка Фенрира предвещал скорый рагнарок, а заказчик все названивал с требованием восстановить работу системы — риски конечно нужно учитывать, но если вы зависите от библиотек, которые завтра могут быть удалены автором, то ваши проблемы несколько масштабнее, нежели вопрос хранения зависимостей в репозитории.
Lisio
15.10.2015 21:58+1Любая библиотека может быть удалена в любой момент времени, независимо от авторства. Не вижу особых проблем в том, чтобы быть к этому готовым. Речь не о хранении вендоров непосредственно в репозитории проекта. Но приведите мне хотя бы один довод, почему бы их не хранить в своем соседнем репозитории.
Delphinum
15.10.2015 22:03Любая библиотека может быть удалена в любой момент времени, независимо от авторства
Давайте не будем впадать в теорию вероятностей. Библиотека то может быть удалена, но обоснованно ли считать это риском для работы системы?
Не вижу особых проблем в том, чтобы быть к этому готовым
Если судить так, то вам не хватит жизни подготовится ко всему что возможно (конечно утрирую)
Но приведите мне хотя бы один довод, почему бы их не хранить в своем соседнем репозитории
Зачем? Если вы зависите от какой то нестабильной библиотеки, при том что есть реальный риск потерять к ней доступ, то никаких вопросов — форкайте репозиторий и пропишите зависимости от вашего форка. За много лет работы в IT сфере я еще никогда не сталкивался с удаленной сторонней библиотекой.Lisio
15.10.2015 22:19+2Честно говоря, хотелось бы более обстоятельного ответа. «Зачем» и «я не сталкивался» в качестве аргументов за/против не очень удачны.
Delphinum
15.10.2015 22:23Мне думается отличные аргументы. Ну ок, приведу другие: у вас может быть множество зависимостей, которые будут так же иметь множество зависимостей и т.д. Хранить их все может быть накладно. С другой стороны разработчики часто обновляют зависимости, это значит что вам придется обновлять свой «соседний репозиторий», тоже довольно накладно. Все это потому, что вы боитесь, что завтра язык на котором вы пишете вдруг станет «вне закона» и вам придется «судорожно переписывать проект на другом ЯП». Глупо, не правда ли?
Lisio
15.10.2015 22:40Куда более накладно содержать сервера бэкапов, держать несколько дополнительных реплик базы на случай падения мастера и т.д. Но мы же не отказывается от всего этого? Хранение даже достаточно большого набора зависимостей совершенно незаметно на этом фоне и не вызывает каких-либо затруднений.
Delphinum
15.10.2015 22:50Но мы же не отказывается от всего этого?
Не отказываюсь, потому что это мне действительно нужно, потому что есть реальные риски срыва сроков и т.д. В описываемой вами проблеме я рисков не вижу.
Хранение даже достаточно большого набора зависимостей совершенно незаметно на этом фоне и не вызывает каких-либо затруднений
Не вызывает, согласен, но вы все еще не ответили на вопрос — зачем? Зачем это нужно, когда и без этого все прекрасно работает и ничего не предвещает беды?Lisio
15.10.2015 23:04Именно затем и нужно, что все прекрасно работает, а через минуту — опа, а ведь ничего не предвещало беды. В моей личной философии версионирования зависимости первого уровня — это основа проекта и очень важная его составляющая. И на вопрос «зачем» я могу ответить — а почему, собственно, нет?
Delphinum
15.10.2015 23:06+1Именно затем и нужно, что все прекрасно работает, а через минуту — опа, а ведь ничего не предвещало беды
Почему же вы не храните в репозитории компилятор того языка, который вы используете?
И на вопрос «зачем» я могу ответить — а почему, собственно, нет?
Вот это плохой аргумент )Lisio
15.10.2015 23:19+1Зачем мне компилятор, если я могу взять бинарник. Зачем мне бинарник, если в мире сотня тысяч человек найдется, кто им пользуется и найти исходиники можно за считанные минуты. А где мне искать библиотеку, которой пользуется сотня человек? Остлеживать ее популярность и качество поддержки репозитория? Выстраивать схему проксирования пакетов, резервируя под нее некоторые мощности и отслеживать корректность работы еще и этой системы, или просто положить код рядом и пусть лежит? Чем это настолько принципиально отличается от хранения composer.lock, кроме места?
Если мы пишем код на php и храним рядом сторонний, но от этого не менее нужный код на php, то повторюсь, абсолютно не вижу в этом проблемы. Ни со стороны ресурсов, ни со стороны поддержки кода. Компилятор — это уже другой уровень зависимости, другой язык, крайность в теме нашей беседы.Delphinum
15.10.2015 23:26Зачем мне компилятор, если я могу взять бинарник
Ну вы же должны скомпилировать ваш проект перед деплоем или не должны?
кто им пользуется и найти исходиники можно за считанные минуты
Открою вам секрет — если у вас разрешены зависимости с помощью composer, то вы сможете найти все исходники от которых вы зависите в считанные секунды открыв каталог vendor.
Выстраивать схему проксирования пакетов, резервируя под нее некоторые мощности и отслеживать корректность работы еще и этой системы, или просто положить код рядом и пусть лежит?
Форкнуть зависимости вместо добавления их в репозиторий проекта.
Чем это настолько принципиально отличается от хранения composer.lock, кроме места?
Есть такая хорошая штука, как инкапсуляция. Если вы льете зависимости в репу вашего проекта, это несколько нарушает инкапсуляцию, не находите? Другими словами — почему вы не храните компилятор языка, который используете, в репозитории вашего проекта? Кто такой Джон Голд? )Lisio
15.10.2015 23:43Ну вы же должны скомпилировать ваш проект перед деплоем или не должны?
Я пишу код на php, phalcon и zephir не использую, что прикажете компилировать?
Открою вам секрет — если у вас разрешены зависимости с помощью composer, то вы сможете найти все исходники от которых вы зависите в считанные секунды открыв каталог vendor.
А нету каталога vendor, или мы теперь надеемся на содержимое рабочей машины программиста?
Есть такая хорошая штука, как инкапсуляция. Если вы льете зависимости в репу вашего проекта, это несколько нарушает инкапсуляцию, не находите?
Чем инкапсуляция для программиста важнее целостности проекта для его владельца?Delphinum
15.10.2015 23:46Я пишу код на php, phalcon и zephir не использую, что прикажете компилировать?
Это не меняет сути вопроса. Перефразирую — почему вы не храните в репозитории проекта PHP интерпретатор или тот же composer?
А нету каталога vendor, или мы теперь надеемся на содержимое рабочей машины программиста?
Зачем мне бинарник, если в мире сотня тысяч человек найдется, кто им пользуется и найти исходиники можно за считанные минуты
Надеюсь вы поняли мыслю.
Чем инкапсуляция для программиста важнее целостности проекта для его владельца?
Да нет, ничем, мысли в слух.Lisio
16.10.2015 00:12Перефразирую — почему вы не храните в репозитории проекта PHP интерпретатор или тот же composer?
Уже дважды отвечал. Поясняю более детально: я пишу скрипты, фреймворк и код других библиотек — это скрипты. Весь проект — исключительно скрипты и немного статики. Не компилируются. Вообще. Никогда.
Надеюсь вы поняли мыслю.
Понял, попытка поймать меня на расхождениях в моих собственных мыслях. Но нет, я программист на php и моя зона ответственности — код скриптов на php. Содержимое папки vendor входит в мою зону ответственности, т.к. а) я выбираю нужные пакеты и строю свой код на их основе; б) они на php. Как только в зону ответственности попадет компиляция непосредственно php, то возникнет вопрос — почему числюсь программистом, а не системным администратором.
Надо сделать оговорку, что свои рассуждения я отношу к проектам уровня сложности чуть выше среднего и ниже. Подход к работе достаточно крупных проектов с очень развитой инфраструктурой будет несколько иным. Там, на мой взгляд, лучше держать копии репозиториев отдельно, но все равно в рамках этой инфрастуктуры, а не на гитхабе и ему подобных. Но, подозреваю, что в таких проектах используется что-то иное, нежели composer, и к теме обсуждения относится едва ли.Delphinum
16.10.2015 00:23Уже дважды отвечал. Поясняю более детально: я пишу скрипты, фреймворк и код других библиотек — это скрипты. Весь проект — исключительно скрипты и немного статики. Не компилируются. Вообще. Никогда.
Либо вы не знаете как исполняется PHP, либо я схожу с ума ) У вас есть скрипты на PHP, вы их запускать должны будете, или вы для того чтобы их на стену повесить пишите?
Понял, попытка поймать меня на расхождениях в моих собственных мыслях. Но нет, я программист...
Понятно. Ну ладно, думаю на этом можно закончить обсуждения, как вы считаете?
phprus
16.10.2015 10:27> Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Почему не храним?
Например, у меня в отдельном репозитории лежат и iso-образы сборочной ОС, и клоны репозитория, и скрипты ее автоустановки и автонастройки, чтобы в любой момент времени нужные виртуальные машины могли быть автоматически пересобраны даже если билд-кластер умрет полностью.
Только вот этот репозиторий не git или svn, а отдельный каталог на файловом сервере.
Да, это занимает дополнительное место, но все это дает мне гарантированную воспроизводимость окружения сборки и всех зависимостей (зависимости проектов я тоже храню у себя), что для меня важно.
Ну и независимость от внешних репозиториев в моменты сборки тоже неплохой бонус, а если сборка всегда проводится на чистых машинах, то для загрузчиков зависимостей нужно либо кэши городить, либо каждый билд тащить из интернета сотни мегабайт библиотек.Delphinum
16.10.2015 14:19у меня в отдельном репозитории
Речь не об отдельном репозитории. Перечитайте внимательно статью.phprus
16.10.2015 15:22+1Изначально в статье был вопрос:
> Стоит ли хранить содержимое папки vendor в наших репозиториях?
Для меня наш репозиторий — это все то, что находится под моим управлением, включая условные svn.company.com, git.company.com, files.company.com, pkg.company.com и другие варианты. Гитхаб и репозитории вендоров по этому определению не наши.
Да, в дальнейшем было уточнение, что вопрос следует понимать как «прямо в репозитории с проектом».
Если брать этот вопрос, то на него однозначно я ответить не могу, однако, склоняюсь к мысли, что можно и хранить, так как единственный контраргумент по сути — это размер репозитория, но для меня это не критично. А на девелоперскую и сборочную машину все равно весь этот объем тащить надо для сборки.Delphinum
16.10.2015 15:25-1Зачем вам на девелоперскую машину тащить iso-образы сборочных ОСей?
phprus
16.10.2015 15:31Ох! Конечно же все, что написано во втором абзаце моего предыдущего комментария относится только к зависимостям вида библиотеки и подобное (в папке vendor традиционно хранятся библиотеки).
Delphinum
16.10.2015 15:43-1Вот мы и возвращаемся к вопросу: Почему же вы не храните в репозитории компилятор того языка, который вы используете?
phprus
16.10.2015 15:58Так в том то и дело, что храню!
Не путайте техническое разбиение инфраструктуры на репозитории, сабмодули и прочее с организационной стороной. С организационной точки зрения в моем репозитории есть и компиляторы.Delphinum
16.10.2015 15:59-1Ок, я спрошу по другому: Почему же вы не храните в репозитории (проекта который пишите) компилятор того языка, который вы используете (iso-образы ОСей)?
phprus
16.10.2015 16:08+1Это разный уровень объектов. Инфраструктура компиляции и код проекта — это слабосвязанные между собой вещи, а код и библиотеки — сильно связанные.
Delphinum
16.10.2015 16:54Как это слабосвязанные? А если завтра, внезапно, язык на котором вы будите писать возьмет да удалится отовсюду, вы же не сможете задеплоить свой проект, как не сможете это сделать при отсутствии одной из библиотек. Так в чем разница? И то и другое нужно для успешной работы проекта.
phprus
16.10.2015 17:03Исчезновение библиотек я видел (например, поищите исходники PathScale и библиотек, которые они выкладывали на гитхаб и которые потом исчезли). Исчезновение всего линукса слишком маловероятно. Это во первых.
Во вторых, мой софт использует конкретную версию конкретной библиотеки, ее имеет смысл положить рядом. Компилируется же он в трех десятках окружений гарантированно и я не знаю в скольки еще линуксах скорее всего. Их не имеет смысла держать совсем рядом, при этом, как я уже писал выше, все компоненты окружений и сборки сборочных виртуальных машин аккуратно сложены в отдельном каталоге на файловом сервере.Delphinum
16.10.2015 17:22Исчезновение всего линукса слишком маловероятно
А если было бы вероятно, вы бы залили линуху в репозиторий своего проекта?phprus
16.10.2015 17:52Скажите, пожалуйста, Вы читать умеете?
Для защиты от проблем с линуксом и интернетом у меня линуксы сложены в отдельный репозиторий на файловом сервере. Прочитайте уже перевод слово репозиторий, чтобы перестать ассоциировать его исключительно с системами управления версиями.
Еще раз повторюсь, что в проект имеет смысл складывать сильно связанные компоненты. Слабо связанные имеет смысл хранить, но не в проекте. Тот факт, что свой проект, который я сейчас подразумеваю собирается более чем в 30 окружениях, то каждое отдельное окружение слабо связано с проектом.
Библиотека же может использоваться только конкретной протестированной версии, так как ABI-совместимость и все такое — это сильно связанная компонента.
> github.com/pathscale?
Там есть исходники компилятора, который они выкладывали?
Оно было здесь: http://www.path64.org/ и https://github.com/path64, но исчезло и сылки с path64.org теперь ведут в никуда (например, github.com/path64/compiler).Delphinum
16.10.2015 17:59Скажите, пожалуйста, Вы читать умеете?
Просто вы не улавливаете мою иронию.
Слабо связанные имеет смысл хранить, но не в проекте
При отсутствии библиотеки вам нужно будет переписать часть проекта, а при отсутствии интерпретатора/компилятора — весь проект. Так где же тут слабая связь?
Библиотека же может использоваться только...
composer.lock вас спасет.
Для защиты от проблем с линуксом и интернетом у меня линуксы сложены в отдельный репозиторий на файловом сервере
Что мешает сложить туда же ваши зависимости?phprus
16.10.2015 18:22> Просто вы не улавливаете мою иронию.
Это не похоже на иронию. Это похоже исключительно на глупость, уж простите меня за резкость.
> При отсутствии библиотеки вам нужно будет переписать часть проекта, а при отсутствии интерпретатора/компилятора — весь проект. Так где же тут слабая связь?
При отсутствии, например, Boost проект будет проще переписать с нуля или написать свой аналог буста.
А что касается компиляторов, то какого из 5 разных от 5 разных вендоров? Или всех сразу?
> Что мешает сложить туда же ваши зависимости?
Удобство использования. Один git clone/svn checkout и с проектом можно работать, а с composer придется выполнять дополнительные действия.Delphinum
16.10.2015 18:27Это не похоже на иронию. Это похоже исключительно на глупость, уж простите меня за резкость.
Да вы меня не обидете, можете не стесняться высказываний )
При отсутствии, например, Boost проект будет проще переписать с нуля или написать свой аналог буста.
А что касается компиляторов, то какого из 5 разных от 5 разных вендоров? Или всех сразу?
Ну судя по вашей логике, нужно все сразу.
Удобство использования
А представьте как будет удобно, если вы зальете в проект сразу весь iso-образ ОСи с накатанным на нее проектом и всеми зависимости. Клац одну кнопку и у вас готовый к работе сервер )
Один git clone/svn checkout и с проектом можно работать, а с composer придется выполнять дополнительные действия
У вас composer перерабатывает и вы не хотите платить ему сверхурочные?phprus
16.10.2015 18:36> Ну судя по вашей логике, нужно все сразу.
Ну раз все сразу, то в случае одновременного исчезновения Intel, Microsoft, GNU FSF и Apple, я думаю мне нужно будет искать другую отрасль (скорее всего земледелие), а не думать о том, что будет с моими проектами.
С библиотеками же все проще. Наглядный пример такого исчезновения я Вам привел (с гитхаба кстати).
> А представьте как будет удобно, если вы зальете в проект сразу весь iso-образ ОСи с накатанным на нее проектом и всеми зависимости. Клац одну кнопку и у вас готовый к работе сервер )
И это тоже есть. Все готовые образы виртуальных машин и докер-контейнеры сложены в файловом репозитории. Да, можно довести до одного клика, но в условиях множественных окружений это не имеет смысла на машине разработчика, а на билд-сервере все собирается в один клик на всех окружениях, там это имеет смысл.
> У вас composer перерабатывает и вы не хотите платить ему сверхурочные?
У меня очень ограниченный composer, так как Web-интерфейсы занимают меньшую часть моего времени.
Но даже в случае с composer я предпочитаю не перерабатывать сам и упрощать сервисные задачи. Лишние N Мб зависимостей в репозитории меня при этом не пугают, тем более, что их обновления идут в отдельных коммитах и не замусоривают историю.Delphinum
16.10.2015 19:00Все готовые образы виртуальных машин и докер-контейнеры сложены в файловом репозитории
А что не в репозиторий проекта? Ах да, забыл, это же слабая зависимость. Ну тогда да, согласен, лучше держать под версионный контролем левый код, ведь так проще и composer не напрягается.
vintage
16.10.2015 19:07Потому что компиляторы не кроссплатформенные, да ещё и требуют зачастую в качестве зависимостей системные библиотеки. Была бы возможность — хранил бы рядом. Вот, например, субд OrientDB очень удобно хранить прямо в репе ибо она написана на яве и не требует установки.
Delphinum
17.10.2015 00:38Кажется вы путаете версионный контроль и хранилище )
vintage
17.10.2015 09:36Хранилище данных инъектится в контейнер с субд через докер. А версионный контроль гарантирует, что приложение будет работать с той версией субд, с которой оно протестировано.
Delphinum
17.10.2015 14:38Да? Хмм… Я думал системы версионного контроля создавались для параллельной работы над проектом и возможности восстановить проект в требуемом состоянии, а не для контроля зависимостей и их версий. Можете уточнить, для чего тогда нужен composer.lock?
Fesor
17.10.2015 15:21вообще-то для инфраструктуры и окружения уже придуманы контейнеры, которые как раз таки и занимаются тем что содержат в себе все необходимое окружение. Но даже в этом случае (например если мы используем docker в качестве обертки над контейнерами) в git мы будем хранить только Dockerfile а не билды и прочий шлак. Собранный образ хранится в отдельном репозитории.
Delphinum
17.10.2015 16:30Я разве это оспариваю? Разговоры про компиляторы и ОСи пошли из-за боязни населения внезапно потерять доступ к чему то важному. Народ использует систему версионного контроля как резервное хранилище.
Fesor
17.10.2015 17:28Я больше к аналогии Dockerfile как composer.json, что это так же инструкция как собрать зависимости проекта, а точнее окружение. Но само окружение никто не хранит, хранят только билды для деплоя.
Delphinum
17.10.2015 21:25Почему вы пишете это мне, а не тем людям, которые хранят само окружение в репе проекта? )
phprus
18.10.2015 11:08Случаев, когда реально терялся компилятор или ОС я что-то припомнить не могу. С библиотеками же такое происходит и люди видимо с этим сталкивались. Даже если теряется не сама библиотека, может исчезнуть из апстрима ее старая версия, которая для тестов старой версии ПО потребуется или еще для чего-то подобного.
> Народ использует систему версионного контроля как резервное хранилище.
А почему версии библиотек не должны отслеживаться системами версионного контроля?
Наверное даже спрошу так, почему версия библиотеки в Вашем понимании — это только строка вида 1.2.3?
Вы никогда не патчили библиотеки, не бекпортировали в них изменения из аптрима без обновления всей библиотеки для сохранения ABI/API? По всем этим причинам для меня версии библиотек это не только цифры, но и весь ее код, который должен как минимум логически храниться или быть доступным в репозитории проекта.Fesor
18.10.2015 11:45Вы никогда не патчили библиотеки
fork, патчим, делаем pull request. Только так. В composer.json можно заменить репозиторий на свой пока pull request на рассмотрении.phprus
18.10.2015 12:10Если только так, значит Вам не критична стабильность API/ABI используемых библиотек, раз Вы можете позволить себе постоянно переходить на новые версии без бекпортирования исправлений и патчинга багов.
fork-patch-pull-request — это хорошо и правильно, но исправления войдут только в новую версию, которая может быть несовместима с используемой Вами и Вам придется все делать руками для своей версии.
P.S. Я если что не про Web и php сейчас, а про более общий случай.Fesor
18.10.2015 12:39+1Вам не критична стабильность API/ABI используемых библиотек
Мне кажется это забота авторов библиотек. Я стараюсь не использовать трэш, а если и приходится — закрываю это оберткой так что изменения в библиотеке от версии к версии не особо страшны + покрыто тестами, так что если вдруг API меняется тесты сразу падают.
но исправления войдут только в новую версию, которая может быть несовместима с используемой Вами
Не используйте библиотеки не практикующие семвер, оборачивайте все нестабильное в стабильный интерфейс, и вообще все стороннее закрывать фасадами неплохая идея.
а про более общий случай.
мы тут обсуждаем composer, и да, даже в общем случае все примерно так же. Все плохо только в js мире где большинство пока не доросло до semver. Но и это думаю скоро пройдет.phprus
18.10.2015 13:01-1> Мне кажется это забота авторов библиотек.
Клиенты не к авторам библиотеки придут, если у них что-то сломается, а к Вам.
> Я стараюсь не использовать трэш,
> Не используйте библиотеки не практикующие семвер,
Интересно Вы разработчиков стандарта С++ сейчас обозвали…
К сведению, среди разработчиков Boost есть немало разработчиков стандарта С++.
> закрываю это оберткой
> оборачивайте все нестабильное
Ну то есть полностью перепроектировать и переписать используемую библиотеку.
Посмотрите, как собираются RHEL или SLE и сколько патчей там есть к поставляемым библиотекам и приложениям. Даже если совместимость необходимо поддерживать не 10 лет, а всего год, то применяемые ими методики бекпортирования и багфиксинга придется применять и вам…Fesor
18.10.2015 13:34Ну то есть полностью перепроектировать и переписать используемую библиотеку.
Нет, просто уже лет 20-30 есть довольно удобная идея, не завязывать свое приложение на инфраструктуру. Если вы используете какую-то библиотеку в контексте какой-то задачи — заверните ее в бумажку (фасад, интерфейс). Тогда изменения в инфраструктуре не будут влиять на приложение.
Даже если совместимость необходимо поддерживать не 10 лет, а всего год, то применяемые ими методики бекпортирования и багфиксинга придется применять и вам…
И вот вы сначала перепрыгнули на C++ (у которого традиция хранить зависимости хотя бы через сабмодули идет корнями к проблеме отсутствия вменяемого менеджера пакетов), а теперь вообще на дистрибьютивы linux. Я теряю нить логической связи обсуждаемой проблемы.phprus
18.10.2015 13:39> Нет, просто
См. выше про фреймворки, которые тоже библиотеки по сути. Завернуть фреймворк в обертку — это по сути написать свой.
> И вот вы сначала перепрыгнули
Смотрим начало этой ветки:
> Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Вы знаете компиляторы для PHP? Я нет (HHVM не совсем то). И далее по ветке.Fesor
18.10.2015 14:01Завернуть фреймворк в обертку — это по сути написать свой.
Вы сами сказали что фреймворк это набор библиотек по сути, так что нам не составляет труда завернуть то что нам нужно в интерфейс. Ну и опять же, что бы небыло недопонимания. Фреймворк состоит из кучи библиотек, но большинство из них это реализация интфрейса приложения (http, web, cli, etc) или же работа с базой данных (ORM, DAO). Для того что бы изолировать приложения от фреймворка нам всего-то надо объявить интерфейс взаимодействия внешних частей с приложением (DTO, CQRS) + предоставить изоляцию слоя хранения данных (шаблон репозиторий например). И все. Наше приложение никак не зависит от инфраструктуры. Далее у нас могут быть задачи вроде отправки нотификаций, в этом случае мы объявляем в приложении интерфейс и, используя компоненты фреймворка или же сторонние библиотеки, реализуем этот интерфейс.
На эту тему вы можете посмотреть одну из многочисленных лекций дяди Боба, он об этом уже лет 10 рассказывает всем на примере ruby, java и C++.
Но это я больше в контексте бэкэнда. Если брать клиентские приложения — там примерно так же, но чуть меньше напрягов с изоляцией слоя хранения данных, а от интерфейса нас почти всегд защищает MVC/HMVC архитектура.
Вы знаете компиляторы для PHP? Я нет (HHVM не совсем то). И далее по ветке.
Я знаю как люди работаю с Go или с Dlang. И там так же есть менеджеры пакетов и никто ничего не коммитит. В D например есть DUB, который и версию компилятора проверить вроде может. Вы же выбрали язык, где нет нормального менеджера пакетов, потому там царит хаос (ну я преувеличиваю, там тоже научились с этим жить но чуть по другому). И сторонние зависимости там так же много кто не коммитит, стараются использовать ссылки на репозитории, сабмодули и прочее.
Да и для унификации окружения для сборки выгоднее использовать средства аля Docker, в этом случае мы так же в нашем GIT репозитории будем хранить только серсы, только Dockerfile, рецепт как поднять окружение а не само окружение. Мы можем для уменьшения рисков один раз сбилдить окружение и залить его в какой docker hub что бы не париться больше и ускорить работу.phprus
18.10.2015 14:48> так что нам не составляет труда завернуть то что нам нужно в интерфейс
Чтобы не быть голословным, предложите, пожалуйста, вариант оберток для любой библиотеки из Boost. А потом, скажите, что Вы будете делать, когда после стабилизации и усовершенствования библиотека из Boost попадет в стандарт. Будете поддерживать обертки поверх стандарта (но зачем)? Или с печальным видом избавляться от них переходя обратно на API, который был практически изначально?
> Вы же выбрали язык, где нет нормального менеджера пакетов, потому там царит хаос
Я выбрал тот язык, который для моих задач подходит наиболее хорошо. Скажу даже больше, где-то рядом все еще живее всех живых Fortran (и приносит разработчикам компиляторов денег не меньше чем С++, кстати).
> стараются использовать ссылки на репозитории, сабмодули и прочее.
Перечитайте, пожалуйста, всю ветку. Возможно, тогда Вы увидите, что я про это практически с самого начала говорю.
> выгоднее использовать средства аля Docker
И об этом я тоже писал чуть выше…
К сожалению еще не для всех продуктивных задач докер подходит, но работы в этом отношении идут и перспективы меня радуют.Fesor
18.10.2015 17:11предложите, пожалуйста, вариант оберток для любой библиотеки из Boost
Boost не надо оборачивать, но он же используется для чего-то? так вот это что-то и оборачивается. Ну и да, есть здравый смысл, так что перегибать палку уж не надо. Просто надо стараться изолировать код приложения (бизнес логика и т.д.) от сторонних библиотек и фреймворков. Главные то не они.
С C++ мне сложно предложить пример так как я ничего осбо на нем и не пишу.
Словом… я запутался немного с формулировками. Использование сабмодулей это все же не то же самое что «держать в репозитории». В такой же трактове с этим проблем нет.
phprus
18.10.2015 17:28> так вот это что-то и оборачивается… Просто надо стараться изолировать код приложения (бизнес логика и т.д.)…
Так вот это что-то может быть нашим приложением. Boost очень низкоуровневая штука, чуть выше чем стандартная библиотека языка по сути. А как можно эффективно и со смыслом изолировать бизнес-логику, например, от контейнеров я не знаю.
Конечно, если под библиотеками понимать что-то более высокоуровневое, например, Qt для GUI, то в этом случае отделять бизнес-логику от собственно GUI вполне понятно как и необходимо.
VolCh
18.10.2015 17:48+1Просто надо стараться изолировать код приложения (бизнес логика и т.д.) от сторонних библиотек и фреймворков. Главные то не они.
И потому держать их в репозитории приложения нет никакого смысла :)
vintage
15.10.2015 22:09+3А вы используете только библиотеки, которые не могут быть удалены никогда, ни при каких обстоятельствах?
Наедет какой-нибудь копираст и опа, вы не можете задеплоиться и начинаете судорожно пихать пропавшие из репозитория модули в свой репозиторий с кодом.Delphinum
15.10.2015 22:12А вы используете только библиотеки, которые не могут быть удалены никогда, ни при каких обстоятельствах?
Для интереса пробежался по зависимостям моего текущего проекта и могу с гордостью ответить — да
Наедет какой-нибудь копираст и опа, вы не можете задеплоиться и начинаете судорожно пихать пропавшие из репозитория модули в свой репозиторий с кодом
Зачем что то куда то пихать? Все зависимости я могу восстановить себе из локальной копии проекта, а если их еще и залить на корпаративный git репозиторий и поправить composer.json, то все сразу заработает.vintage
15.10.2015 22:40Вы либо врёте, либо заблуждаетесь. Ни то, ни другое не делает вам чести.
Не важно куда вы будете их пихать. Важно то, что вы узнаете о проблеме лишь при деплое. Не говоря уж о том, что вам может потребоваться «размораживать» проект, имея лишь репу с исходниками на руках.
Вот вы можете назвать хоть одну причину не хранить зависимости в репозитории, кроме как незначительное увеличение его объёма? Эта причина правда стоит того, чтобы придумывать сложные схемы с локами версий, локальными зеркалами репозиториев на сборочном сервере, терпеть медленную сборку, переключение веток и bisect, шаманством для выяснения что именно поменялось в коде зависимостей? Ну вот честно, правда оно того стоит?Delphinum
15.10.2015 22:48Вы либо врёте, либо заблуждаетесь. Ни то, ни другое не делает вам чести.
С чего же такие выводы, что на их основании вы меня уже начали обвинять? )
Не важно куда вы будете их пихать
Так важна ли возможность непрерывного деплоя или не важна?
Вот вы можете назвать хоть одну причину не хранить зависимости в репозитории, кроме как незначительное увеличение его объёма?
Да, уже отвечал на этот вопрос немного выше.
Ну вот честно, правда оно того стоит?
Стоит ли пользоваться системами сборки, деплоя, автоматического тестирования, контроля версий, контроля задач, когда можно пойти более простым путем и не пользоваться этим?
VolCh
16.10.2015 12:14-1Вот вы можете назвать хоть одну причину не хранить зависимости в репозитории, кроме как незначительное увеличение его объёма?
шаманством для выяснения что именно поменялось в коде зависимостей?
Основная причина: подавляющее большинство времени при работе над проектом я не хочу знать, что поменялось в коде зависимостей — вполне достаточно диффа composer.json для того, чтобы знать как коллеги поменяли зависимости, даже диффы composer.lock раздражают в коммитах, но это меньшее зло чем что не хранить версии зависимостей вообще, чем что хранить не только «номера» версий, но и их самих.
Blumfontein
16.10.2015 06:47Кирпич вам на голову может прилететь с гораздо большей вероятностью, и последствия куда фатальнее. Вы наверх всегда смотрите, когда рядом с высотными домами ходите?
Borro
15.10.2015 21:50+2Хранить нельзя. Чтобы зафиксировать версии, вам нужно хранить composer.lock в репозитории.
Если вы боитесь, что будут недоступны какие-то проекты и пакеты, воспользуйтесь проксированием packagist.org с помощью разных систем, например SatisLisio
15.10.2015 22:49+1Хранить можно. Чтобы не выстраивать целую архитектуру в виде проксирования с помощью разных систем, добавляя лишние звенья, достаточно просто хранить используемый сторонний открытый код где-то рядышком.
t1gor
15.10.2015 22:53где-то рядышком
так ведь это ключевое замечание. Обсуждение подразумевает хранение вендорского кода прямо в репозитории с проектом. В одном репозитории.Borro
16.10.2015 00:29+1Сатис работает на php в кроне, а отдаёт статику nginx'ом, никаких заморотов, зато полное версионирование ваших пакетов. Если нужно будет поставить предыдущию версию, она всегда будет в сатис.
Прямо в репозитории хранить нельзя, т.к. это лишний код в репозитории, который по факту не нужен. Если очень хочется, можете попробовать хранить как сабмодуль, но это тоже идея не самая хорошая.
misterion
15.10.2015 23:16C сатисом не удобно то, что добавлять пакеты нужно руками. Если хочется комфортного и прозрачного проксирования то лучше Toran Proxy — коммерческий аналог Satis от автора composer. Он автоматически умеет кешировать и обновлять пакеты, если его прописать как замену packinst.org. Он в таком случае всегда стягивает себе отсутствующие пакеты себе и отдает вам их из локального хранилища.
t1gor
15.10.2015 23:55У меня тоже была мысль привести его в качестве примера. Вопрос только в том, что он платный, а значит обосновать придется хорошенечко. Пробовали его в своих проектах?
misterion
16.10.2015 00:35Да, практически с момента его выхода. До этого использовали сатис и для внутренних пакетов и для наиболее часто используемых важных внешних. Был какой-то период когда у нас постоянно были проблемы то с доступностью гитхаба, откуда тянулось пара наших открытых пакетов, потом был период с недоступностью или лагами самого сайта packagist.org. Это регулярно разбавлялось проблемами нашего основного провайдера в офисе. Торан реальная палочка выручалочка — всё равно есть интернет, нет интернета и что сейчас доступно, а что нет, всё стянется из локальной копии на его сервере. В целом — очень рекомендую.
amaksr
16.10.2015 00:24-1Не знаю, возможно ли такое на packagist-е, но на rubygems-е у меня один раз такое было, что файл lock ссылался на gem, которые был yanked из репозитроия, благодаря чему грузилась следующая версия gem-а, которая не была совместима с приложением. В результате gem пришлось вытаскиваить со старого компа одного из девелоперов, где он чудом сохранился. Поэтому я однозначно за хранение копий всех зависимостей в репозитории проекта. А в случае Ruby так еще и всю директорию с Ruby лучше зачекинить.
zayceslav
16.10.2015 07:27В таком случае можно попробовать с продакшена вытянуть старую версию. По идее, подобная проблема если и случится, то до релиза.
maxru
16.10.2015 10:57После прочтения комментариев, очень хочется цитировать Лаврова, но кролик очень вежливый, поэтому не будет.
maximw
16.10.2015 15:02Есть ноут, на котором я пишу код и где-то далеко есть некая песочница, куда этот код синхронизируется и где я смотрю результат, отлаживаю (отделяю код от лажи :)).
Все начинается с того, что я клонирую себе репу проекта.
Если вендорские библиотеки лежат в репе, я сразу их получаю.
- У меня в IDE сразу работает навигация по классам этих библиотек.
- Я работаю с одним инструментом — git.
- Код (а не мета-информация) библиотеки фиксирован, и мне наплевать, что случится с репой самой библиотеки, даже если им вздумается ее удалить или внеси изменения в текущую версию задним числом, и все сломать.
Если библиотек там нет, то
- Чтоб работала навигация IDE мне надо дополнительно поставить себе на ноут PHP и композер, и еще не забаывать его запускать в случае обновлений.
- Я завишу от людей, которых не знаю. И если версию библиотеки можно зафиксировать в composer.lock, то как зафиксировать желание ее разрабочиков что-то изменить в ее коде без подъема ее версии?
Я доверяю библиотеке на некоторый момент ее скачивания, когда я это дело контролирую. После этого я должен доверять другим людям, потому что каждый раз скачивать ее будет композер без моего участия.
Да, можно использовать свои форки, свои packagistы, какой-то проксирующий софт. Но едва ли это более удобно, чем видеть коммиты с апдейтом библиотек в своей репе. (Причем, в виде бонуса видеть что именно там поменялось без допольнительных diff-утилит.)
t1gor
16.10.2015 15:54Не могу согласиться, к сожалению: при маленьком изменении в вашем коде с большим изменением (например — мажорная версия) в вендорском коде,
выревьюер в diff-е ничего путного не увидит. Сам change вашего кода может быть вообще в этой куче потерян.maximw
16.10.2015 15:59+1Обновление бибилотек надо делать отдельными коммитами. Всего лишь немного дисциплины при обращении с репой.
Ну либо я что-то упускаю из виду.Blumfontein
17.10.2015 09:49>> Обновление бибилотек надо делать отдельными коммитами
А как это вам поможет, если вы делаете один пул реквест?vintage
17.10.2015 10:39А в чём проблема сделать один пул реквест с несколькими коммитами?
Blumfontein
17.10.2015 10:56Ну да вообще-то, список всех коммитов и каждый в отдельности можно посмотреть при пулл-реквесте.
VolCh
18.10.2015 17:46А при ревьюировании кода надо эти коммиты смотреть?
и еще не забаывать его запускать в случае обновлений.
Всего лишь немного дисциплины
XEK
В общем случае — нет, не стоит, именно для этого придумана модуляризация и package-менеджеры.
Но как только возникает или потребность переделки(доделки) чужого кода или жесткие бизнес-требования, что «должно работать из коробки в любой момент, мы не можем что-то скачивать из инета» и все такое — тогда да, стоит хранить рядом.
Как и у любой более-менее серьезной инженерной задачи решения есть разные, зависящие от обстоятельств.
XEK
К сожалению, есть и печальная тенденция с пакетами, я ее замечал в среде javascript и python-разработчиков, когда у любого мало-мальски простого проекта 15 зависимостей, и среди них юмор типа «debug»: "~2.1.1", «serve-favicon»: "~2.2.0" (реальнй пример из Kibana4).
Так что есть и тенденция в работе предпринимать усилия по избавлению от такой «лапши».
alekciy
По хорошему это должно решать на уровне некоего центрального репозитория. Но это кропотливая работа по ревью кода с целью выяснения реальной необходимости зависимостей. Не понятно, кто этим будет заниматься. Более реальный вариант это наверное явный призыв к сообществу вносить в пакет как можно меньше зависимостей. Остальное уже будет зависеть от адекватности сообщества.
t1gor
на уровне компании / проекта или всего php сообщества?
alekciy
Я как раз именно про сообщество, а не какой-то конкретный проект (с проектом как раз все понятно, там «ответственный человек, aka team-lead / architect»).
t1gor
Но ведь эта дискуссия как раз о рабочих проектах, а не библиотеках, которые вы выкладываете на GitHub. С ними, в свою очередь, тоже все понятно.
alekciy
С проектами тоже и так все понятно ) (о чем в том числе написано на самом composer). Есть composer.json, есть composer.lock. В репозитории проекта стороннего кода быть не должно и не может быть. Если автор забросил/забил на запросы на слияние и приходится держать свой форк, то она приходит в проекта так же как сторонний код (т.е. в vendors). Просто на руках тогда имеет уже два проекта которые нужно поддерживать: текущий и форк сторонней либы.
symbix
Хранить зависимости — как копии, так и форки — можно (и нужно) в своем корпоративном packagist-е, он поднимается на раз-два. Хранить в репозитории именно папку vendor причин нет вообще.
saksmt
Если уж так приспичило поменять вендора есть 2 нормальных выхода, без загаживания дерева:
nazarpc
Тогда нужно делать форк и поддерживать пока патч не примут upstream, и подключать в зависимости форк.
Либо копировать библиотеку мимо vendor и четко документировать примененные патчи.
Редактировать что-то в vendor это жесть, потом же голову сломать можно.
zBit
Переделывать или доделывать сторонние библиотеки — это мега-плохо. Поправьте, если я не прав. Правило хорошего тона — установить жёсткие версии в зависимостях. И вместо переделки чужого кода, кто мешает создать новый класс, отнаследовать в нём тот класс, который надо переделать и заменить/дополнить реализацию нужного метода и использовать его?
neolink
реализация зачастую мешает, да и вообще в чем проблема сделать форк, поправить, сделать pull-requst разработчику, обычно их принимают, а если нет, то и новых коммитов в основной ветке тоже не появляется, что значит в своем форке вы тоже не отстанете сильно
VolCh
Нередко основной разработчик библиотеки может заявить «это не баг — это фича» и продолжать активную разработку игнорируя реквест. Опыт показывает, что после такого отклонения реквеста имеет смысл или отказаться от «багофичефикса», или переходить на аналоги, или активно поддерживать свой форк, забирая изменения из апстрима точечено.
neolink
и такое может быть, но хотя бы это будет сделано в 1 месте, а не в каждом проекте