Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 141
В общем случае — нет, не стоит, именно для этого придумана модуляризация и package-менеджеры.
Но как только возникает или потребность переделки(доделки) чужого кода или жесткие бизнес-требования, что «должно работать из коробки в любой момент, мы не можем что-то скачивать из инета» и все такое — тогда да, стоит хранить рядом.
Как и у любой более-менее серьезной инженерной задачи решения есть разные, зависящие от обстоятельств.
Но как только возникает или потребность переделки(доделки) чужого кода или жесткие бизнес-требования, что «должно работать из коробки в любой момент, мы не можем что-то скачивать из инета» и все такое — тогда да, стоит хранить рядом.
Как и у любой более-менее серьезной инженерной задачи решения есть разные, зависящие от обстоятельств.
К сожалению, есть и печальная тенденция с пакетами, я ее замечал в среде javascript и python-разработчиков, когда у любого мало-мальски простого проекта 15 зависимостей, и среди них юмор типа «debug»: "~2.1.1", «serve-favicon»: "~2.2.0" (реальнй пример из Kibana4).
Так что есть и тенденция в работе предпринимать усилия по избавлению от такой «лапши».
Так что есть и тенденция в работе предпринимать усилия по избавлению от такой «лапши».
По хорошему это должно решать на уровне некоего центрального репозитория. Но это кропотливая работа по ревью кода с целью выяснения реальной необходимости зависимостей. Не понятно, кто этим будет заниматься. Более реальный вариант это наверное явный призыв к сообществу вносить в пакет как можно меньше зависимостей. Остальное уже будет зависеть от адекватности сообщества.
Не понятно, кто этим будет заниматься.ну почему же — в каждой команде есть обычно ответственный человек, aka team-lead / architect который должен принимать подобные решения.
По хорошему это должно решать на уровне некоего центрального репозитория.на уровне компании / проекта или всего php сообщества?
Я как раз именно про сообщество, а не какой-то конкретный проект (с проектом как раз все понятно, там «ответственный человек, aka team-lead / architect»).
Но ведь эта дискуссия как раз о рабочих проектах, а не библиотеках, которые вы выкладываете на GitHub. С ними, в свою очередь, тоже все понятно.
С проектами тоже и так все понятно ) (о чем в том числе написано на самом composer). Есть composer.json, есть composer.lock. В репозитории проекта стороннего кода быть не должно и не может быть. Если автор забросил/забил на запросы на слияние и приходится держать свой форк, то она приходит в проекта так же как сторонний код (т.е. в vendors). Просто на руках тогда имеет уже два проекта которые нужно поддерживать: текущий и форк сторонней либы.
Хранить зависимости — как копии, так и форки — можно (и нужно) в своем корпоративном packagist-е, он поднимается на раз-два. Хранить в репозитории именно папку vendor причин нет вообще.
Если уж так приспичило поменять вендора есть 2 нормальных выхода, без загаживания дерева:
- Патч, совсем не сложнно делается между прочим
- Форк и пул-реквест, заодно и всем остальным пользователям библиотеки жизнь упростите в случае бага
Тогда нужно делать форк и поддерживать пока патч не примут upstream, и подключать в зависимости форк.
Либо копировать библиотеку мимо vendor и четко документировать примененные патчи.
Редактировать что-то в vendor это жесть, потом же голову сломать можно.
Либо копировать библиотеку мимо vendor и четко документировать примененные патчи.
Редактировать что-то в vendor это жесть, потом же голову сломать можно.
Переделывать или доделывать сторонние библиотеки — это мега-плохо. Поправьте, если я не прав. Правило хорошего тона — установить жёсткие версии в зависимостях. И вместо переделки чужого кода, кто мешает создать новый класс, отнаследовать в нём тот класс, который надо переделать и заменить/дополнить реализацию нужного метода и использовать его?
реализация зачастую мешает, да и вообще в чем проблема сделать форк, поправить, сделать pull-requst разработчику, обычно их принимают, а если нет, то и новых коммитов в основной ветке тоже не появляется, что значит в своем форке вы тоже не отстанете сильно
Нередко основной разработчик библиотеки может заявить «это не баг — это фича» и продолжать активную разработку игнорируя реквест. Опыт показывает, что после такого отклонения реквеста имеет смысл или отказаться от «багофичефикса», или переходить на аналоги, или активно поддерживать свой форк, забирая изменения из апстрима точечено.
Изменения в vendor не должно быть. Иначе делайте свой репозиторий и его реквариуем.
Храним composer.lock При деплои используем composer install. Так мы гарантируем идентичность. Любой composer update это мердж.
Храним composer.lock При деплои используем composer install. Так мы гарантируем идентичность. Любой composer update это мердж.
Тоже согласен, в случае, если нет уверенности в «успешной и долгой» жизни используемого пакета в vendor или у вас достаточно сильно выражена паранойя можно попросту сделать его форк (что благодаря github делается в полтора клика). Да, это все же будет отнимать определенное время на обслуживание сторонней библиотеки(мержи и т д) но вы будете уверены в том, что до тех пор, пока вам необходим данный пакет он будет доступен.
Плюс, если у вас имеется механизм «релиза» (аналогичный github) можно прикреплять «скомпилированные» версии вашего продукта с включенной папкой vendor на дату релиза.
Плюс, если у вас имеется механизм «релиза» (аналогичный github) можно прикреплять «скомпилированные» версии вашего продукта с включенной папкой vendor на дату релиза.
Если бы вы этого не написали, это нужно было бы написать!
Я случайно проголосовал за «Не стоит» но на самом деле я считаю что стоит и в своих проектах так и делаю.
Основная причина, потому что когда в репозитории переключаешься с ноды на ноду, с ветки на ветку — уходит очень много времени чтобы выполнить `composer update`, а когда код в репозитории — это делается моментально. Почему бы НЕ хранить библиотеки в репозиториии — я не вижу, размер меня не беспокоит, 40MB (в моём случае) не такой существенный размер, можен быть и намного больше.
Вторая причина, когда делаешь diff двух веток (в меркуриале, TortoiseHg просто выделаешь две ноды и выбираешь «Visual Diff», при этом у меня открывается Araxis Merge) можно быстро посмотреть не только дифф своего кода но и библиотек, если они изменились.
Основная причина, потому что когда в репозитории переключаешься с ноды на ноду, с ветки на ветку — уходит очень много времени чтобы выполнить `composer update`, а когда код в репозитории — это делается моментально. Почему бы НЕ хранить библиотеки в репозиториии — я не вижу, размер меня не беспокоит, 40MB (в моём случае) не такой существенный размер, можен быть и намного больше.
Вторая причина, когда делаешь diff двух веток (в меркуриале, TortoiseHg просто выделаешь две ноды и выбираешь «Visual Diff», при этом у меня открывается Araxis Merge) можно быстро посмотреть не только дифф своего кода но и библиотек, если они изменились.
Ну и ещё один маленький плюс, если у вас деплой происходит из системы контроля версий, опять таки, из неё всё достаётся быстрее, чем достать код из репозитория + сделать достаточно долгий composer install.
Зачем вы делаете composer update, когда надо делать composer install? При наличии lock-файла и всех вендоров в кэше composer install в интернет не ходит и ставит все мгновенно.
Если версии библиотек в composer.json изменились и вы делаете install то получаете такое сообщение
Так что нужно делать именно «composer update»
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»
Это значит, что произошел рассинхрон между composer.json и composer.lock, и тому, кто в таком виде закоммитил код, надо крепко по рукам надавать.
Да, действительно, вы правы, если lock соответствует composer.json, то изменение версий происходит быстрее, не момнетально но существенно быстрее, чтобы в общем-то этот пункт снять.
Но в остальном, в принципе, узнав это я врядли удалю vendor из репозитория, потому что я по сути всё ещё не вижу в этом недостатков, а плюсы всё ещё есть:
Но в остальном, в принципе, узнав это я врядли удалю vendor из репозитория, потому что я по сути всё ещё не вижу в этом недостатков, а плюсы всё ещё есть:
- Всё таки свитч чуть быстрее
- Не нужно настраивать хуки чтобы они делали composer install
- Как я уже говорил, можно быстро посмотреть дифф библиотек и увидеть полную картину изменений от версии к версии
- Всё таки деплой быстрее, так как кешей в чистом контейнере нет и там нужно делать install
- Плюс когда делаешь install теоретически могут быть проблемы с репозиториями, всё таки они не 100% времени доступны, в России бывали случаи и блокировки GitHub'a.
- Кто знает, что прийдёт в голову разработчику того или иного пакета, вдпруг он решит удалить свой репозиторий. Такая версоятость мала, но тоже не стоит совсем её исключать.
Последние 2 пункта можно решить с помощью Satis. Он проксирует запросы на Packegist и умеет сохранять пакеты у себя.
Всё таки свитч чуть быстрее
как мы уже выяснили .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.
Кто знает, что прийдёт в голову разработчику того или иного пакета, вдпруг он решит удалить свой репозиторий.
Это риск работы с любым сторонним пакетом. Как правило это либо бесполезный шлак либо можно сделать зеркало на гитхабах.
"Я просто оставлю это здесь", в теме в которой меня заминусовали за оправдание подобного подхода ;)
https://habrahabr.ru/post/280206/
https://habrahabr.ru/post/280206/
Решение команды разработчиков ESLint было довольно радикальным, но вполне рабочим. Они решили опубликовать пакет ESLint со всеми зависимостями. То есть скачивая архив ESLint, утилита npm скачает также и весь рабочий node_modules для необходимой версии ESLint.
Вот внизу тоже оставили ссылу на подобную тему, про npm habrahabr.ru/post/185200
Я с её автором в принципе согласен. К стати, иронично, что в проектах по работе, где у нас используется node/npm — мы не храним депенденси в репозитории :)
Я с её автором в принципе согласен. К стати, иронично, что в проектах по работе, где у нас используется node/npm — мы не храним депенденси в репозитории :)
«Желаемого эффекта «неизменности» можно достичь жесткой фиксацией версии библиотеки в composer.json.»
Для этого придумали composer.lock
Для этого придумали composer.lock
Это часть нашего приложения, за которое мы несем ответственность
Вы не несете ответственность за сторонние библиотеки, даже если зависите от них.
отсутствие контроля над разработкой стороннего кода. В случае закрытия или «плохого кода» в проекте вендора, мы теряем функциональность
Если вы этого боитесь, пойдите по пути Microsoft и пишите все с нуля «заимствуя» (или покупая) идеи у сторонних разработчиков.
Я просто оставлю это здесь :-)
http://habrahabr.ru/post/185200/
http://habrahabr.ru/post/185200/
Я просто добавлю это между двумя «просто оставлю это здесь».
getcomposer: The general recommendation is no.
getcomposer: The general recommendation is no.
Это устаревшая инфа. Вот новая: docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git
Я просто оставлю это здесь :-)
toster.ru
toster.ru
Мне не хватило доводов в пользу отказа от хранения вендорского кода локально, именно по этому я написал сюда, а не на тостер. Мне нужны аргументы за и против + статистика по опросу. По-моему Хабр для этого и создан, разве нет?
Надо хранить, потому что Maven практически на 100% гарантирует, что зависимость никто не удалит из рапозитория, а композер часто завязан на левые git репозитории, которые могут удалить авторы библиотек, к тому же у Maven более серьезные требования к зависимостям.
Ну это скорее вопрос выбора библиотек, получается. Понятно, что не нужно тянуть в проект все, что «подходит по теме». В данном случае имеются в виду официальные SDK для сторонних API, например, или инструменты автоматизации.
Достаточно делать локальный форк используемых библиотек.
Никогда не стоит. Для этого сделан composer.lock
Даже если идет модификация внешних либ, то это делается в отдельных форках (пусть и приватных) и при деплое собирается максимум из кэша.
Хранить вендоров в репо — это верх сказочности )) Те кто это предлагал, не сторонники ли того товарища, который верит в то, что скоро программисты не нужны и компьютер будет писать код?
Даже если идет модификация внешних либ, то это делается в отдельных форках (пусть и приватных) и при деплое собирается максимум из кэша.
Хранить вендоров в репо — это верх сказочности )) Те кто это предлагал, не сторонники ли того товарища, который верит в то, что скоро программисты не нужны и компьютер будет писать код?
Давайте представим ситуацию: боевой сервер сгорел, в бэкапах вендоры не хранятся, автор свой репозиторий удалил. Какие действия?
У любого девелопера есть на машинке точная копия вендоров по composer.lock'у
Даже если гитхаб взорвется, прелесть гита в том, что ему не нужен центральный сервер.
Использовать ненадежные либы в проекте тоже странно. Короче бежать надо с такой организации, где люди основ пакетирования не внемлют (будь то композер, нпм или еще что).
Даже если гитхаб взорвется, прелесть гита в том, что ему не нужен центральный сервер.
Использовать ненадежные либы в проекте тоже странно. Короче бежать надо с такой организации, где люди основ пакетирования не внемлют (будь то композер, нпм или еще что).
Точная копия на конкретную версию composer.lock, не факт, что на ту, что была на боевом сервере.
Вообще-то факт. Конечно при условии что при деплое на бою не забыли нажать `composer install`.
composer.lock при любом изменении (обновление коммита в либе или версии) себя самоподписывает.
composer.lock при любом изменении (обновление коммита в либе или версии) себя самоподписывает.
Вы забыли еще добавить к этой картине: вой волка Фенрира предвещал скорый рагнарок, а заказчик все названивал с требованием восстановить работу системы — риски конечно нужно учитывать, но если вы зависите от библиотек, которые завтра могут быть удалены автором, то ваши проблемы несколько масштабнее, нежели вопрос хранения зависимостей в репозитории.
Любая библиотека может быть удалена в любой момент времени, независимо от авторства. Не вижу особых проблем в том, чтобы быть к этому готовым. Речь не о хранении вендоров непосредственно в репозитории проекта. Но приведите мне хотя бы один довод, почему бы их не хранить в своем соседнем репозитории.
Любая библиотека может быть удалена в любой момент времени, независимо от авторства
Давайте не будем впадать в теорию вероятностей. Библиотека то может быть удалена, но обоснованно ли считать это риском для работы системы?
Не вижу особых проблем в том, чтобы быть к этому готовым
Если судить так, то вам не хватит жизни подготовится ко всему что возможно (конечно утрирую)
Но приведите мне хотя бы один довод, почему бы их не хранить в своем соседнем репозитории
Зачем? Если вы зависите от какой то нестабильной библиотеки, при том что есть реальный риск потерять к ней доступ, то никаких вопросов — форкайте репозиторий и пропишите зависимости от вашего форка. За много лет работы в IT сфере я еще никогда не сталкивался с удаленной сторонней библиотекой.
Честно говоря, хотелось бы более обстоятельного ответа. «Зачем» и «я не сталкивался» в качестве аргументов за/против не очень удачны.
Мне думается отличные аргументы. Ну ок, приведу другие: у вас может быть множество зависимостей, которые будут так же иметь множество зависимостей и т.д. Хранить их все может быть накладно. С другой стороны разработчики часто обновляют зависимости, это значит что вам придется обновлять свой «соседний репозиторий», тоже довольно накладно. Все это потому, что вы боитесь, что завтра язык на котором вы пишете вдруг станет «вне закона» и вам придется «судорожно переписывать проект на другом ЯП». Глупо, не правда ли?
Куда более накладно содержать сервера бэкапов, держать несколько дополнительных реплик базы на случай падения мастера и т.д. Но мы же не отказывается от всего этого? Хранение даже достаточно большого набора зависимостей совершенно незаметно на этом фоне и не вызывает каких-либо затруднений.
Но мы же не отказывается от всего этого?
Не отказываюсь, потому что это мне действительно нужно, потому что есть реальные риски срыва сроков и т.д. В описываемой вами проблеме я рисков не вижу.
Хранение даже достаточно большого набора зависимостей совершенно незаметно на этом фоне и не вызывает каких-либо затруднений
Не вызывает, согласен, но вы все еще не ответили на вопрос — зачем? Зачем это нужно, когда и без этого все прекрасно работает и ничего не предвещает беды?
Именно затем и нужно, что все прекрасно работает, а через минуту — опа, а ведь ничего не предвещало беды. В моей личной философии версионирования зависимости первого уровня — это основа проекта и очень важная его составляющая. И на вопрос «зачем» я могу ответить — а почему, собственно, нет?
Именно затем и нужно, что все прекрасно работает, а через минуту — опа, а ведь ничего не предвещало беды
Почему же вы не храните в репозитории компилятор того языка, который вы используете?
И на вопрос «зачем» я могу ответить — а почему, собственно, нет?
Вот это плохой аргумент )
Зачем мне компилятор, если я могу взять бинарник. Зачем мне бинарник, если в мире сотня тысяч человек найдется, кто им пользуется и найти исходиники можно за считанные минуты. А где мне искать библиотеку, которой пользуется сотня человек? Остлеживать ее популярность и качество поддержки репозитория? Выстраивать схему проксирования пакетов, резервируя под нее некоторые мощности и отслеживать корректность работы еще и этой системы, или просто положить код рядом и пусть лежит? Чем это настолько принципиально отличается от хранения composer.lock, кроме места?
Если мы пишем код на php и храним рядом сторонний, но от этого не менее нужный код на php, то повторюсь, абсолютно не вижу в этом проблемы. Ни со стороны ресурсов, ни со стороны поддержки кода. Компилятор — это уже другой уровень зависимости, другой язык, крайность в теме нашей беседы.
Если мы пишем код на php и храним рядом сторонний, но от этого не менее нужный код на php, то повторюсь, абсолютно не вижу в этом проблемы. Ни со стороны ресурсов, ни со стороны поддержки кода. Компилятор — это уже другой уровень зависимости, другой язык, крайность в теме нашей беседы.
Зачем мне компилятор, если я могу взять бинарник
Ну вы же должны скомпилировать ваш проект перед деплоем или не должны?
кто им пользуется и найти исходиники можно за считанные минуты
Открою вам секрет — если у вас разрешены зависимости с помощью composer, то вы сможете найти все исходники от которых вы зависите в считанные секунды открыв каталог vendor.
Выстраивать схему проксирования пакетов, резервируя под нее некоторые мощности и отслеживать корректность работы еще и этой системы, или просто положить код рядом и пусть лежит?
Форкнуть зависимости вместо добавления их в репозиторий проекта.
Чем это настолько принципиально отличается от хранения composer.lock, кроме места?
Есть такая хорошая штука, как инкапсуляция. Если вы льете зависимости в репу вашего проекта, это несколько нарушает инкапсуляцию, не находите? Другими словами — почему вы не храните компилятор языка, который используете, в репозитории вашего проекта? Кто такой Джон Голд? )
Ну вы же должны скомпилировать ваш проект перед деплоем или не должны?
Я пишу код на php, phalcon и zephir не использую, что прикажете компилировать?
Открою вам секрет — если у вас разрешены зависимости с помощью composer, то вы сможете найти все исходники от которых вы зависите в считанные секунды открыв каталог vendor.
А нету каталога vendor, или мы теперь надеемся на содержимое рабочей машины программиста?
Есть такая хорошая штука, как инкапсуляция. Если вы льете зависимости в репу вашего проекта, это несколько нарушает инкапсуляцию, не находите?
Чем инкапсуляция для программиста важнее целостности проекта для его владельца?
Я пишу код на php, phalcon и zephir не использую, что прикажете компилировать?
Это не меняет сути вопроса. Перефразирую — почему вы не храните в репозитории проекта PHP интерпретатор или тот же composer?
А нету каталога vendor, или мы теперь надеемся на содержимое рабочей машины программиста?
Зачем мне бинарник, если в мире сотня тысяч человек найдется, кто им пользуется и найти исходиники можно за считанные минуты
Надеюсь вы поняли мыслю.
Чем инкапсуляция для программиста важнее целостности проекта для его владельца?
Да нет, ничем, мысли в слух.
Перефразирую — почему вы не храните в репозитории проекта PHP интерпретатор или тот же composer?
Уже дважды отвечал. Поясняю более детально: я пишу скрипты, фреймворк и код других библиотек — это скрипты. Весь проект — исключительно скрипты и немного статики. Не компилируются. Вообще. Никогда.
Надеюсь вы поняли мыслю.
Понял, попытка поймать меня на расхождениях в моих собственных мыслях. Но нет, я программист на php и моя зона ответственности — код скриптов на php. Содержимое папки vendor входит в мою зону ответственности, т.к. а) я выбираю нужные пакеты и строю свой код на их основе; б) они на php. Как только в зону ответственности попадет компиляция непосредственно php, то возникнет вопрос — почему числюсь программистом, а не системным администратором.
Надо сделать оговорку, что свои рассуждения я отношу к проектам уровня сложности чуть выше среднего и ниже. Подход к работе достаточно крупных проектов с очень развитой инфраструктурой будет несколько иным. Там, на мой взгляд, лучше держать копии репозиториев отдельно, но все равно в рамках этой инфрастуктуры, а не на гитхабе и ему подобных. Но, подозреваю, что в таких проектах используется что-то иное, нежели composer, и к теме обсуждения относится едва ли.
Уже дважды отвечал. Поясняю более детально: я пишу скрипты, фреймворк и код других библиотек — это скрипты. Весь проект — исключительно скрипты и немного статики. Не компилируются. Вообще. Никогда.
Либо вы не знаете как исполняется PHP, либо я схожу с ума ) У вас есть скрипты на PHP, вы их запускать должны будете, или вы для того чтобы их на стену повесить пишите?
Понял, попытка поймать меня на расхождениях в моих собственных мыслях. Но нет, я программист...
Понятно. Ну ладно, думаю на этом можно закончить обсуждения, как вы считаете?
> Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Почему не храним?
Например, у меня в отдельном репозитории лежат и iso-образы сборочной ОС, и клоны репозитория, и скрипты ее автоустановки и автонастройки, чтобы в любой момент времени нужные виртуальные машины могли быть автоматически пересобраны даже если билд-кластер умрет полностью.
Только вот этот репозиторий не git или svn, а отдельный каталог на файловом сервере.
Да, это занимает дополнительное место, но все это дает мне гарантированную воспроизводимость окружения сборки и всех зависимостей (зависимости проектов я тоже храню у себя), что для меня важно.
Ну и независимость от внешних репозиториев в моменты сборки тоже неплохой бонус, а если сборка всегда проводится на чистых машинах, то для загрузчиков зависимостей нужно либо кэши городить, либо каждый билд тащить из интернета сотни мегабайт библиотек.
Почему не храним?
Например, у меня в отдельном репозитории лежат и iso-образы сборочной ОС, и клоны репозитория, и скрипты ее автоустановки и автонастройки, чтобы в любой момент времени нужные виртуальные машины могли быть автоматически пересобраны даже если билд-кластер умрет полностью.
Только вот этот репозиторий не git или svn, а отдельный каталог на файловом сервере.
Да, это занимает дополнительное место, но все это дает мне гарантированную воспроизводимость окружения сборки и всех зависимостей (зависимости проектов я тоже храню у себя), что для меня важно.
Ну и независимость от внешних репозиториев в моменты сборки тоже неплохой бонус, а если сборка всегда проводится на чистых машинах, то для загрузчиков зависимостей нужно либо кэши городить, либо каждый билд тащить из интернета сотни мегабайт библиотек.
у меня в отдельном репозитории
Речь не об отдельном репозитории. Перечитайте внимательно статью.
Изначально в статье был вопрос:
> Стоит ли хранить содержимое папки vendor в наших репозиториях?
Для меня наш репозиторий — это все то, что находится под моим управлением, включая условные svn.company.com, git.company.com, files.company.com, pkg.company.com и другие варианты. Гитхаб и репозитории вендоров по этому определению не наши.
Да, в дальнейшем было уточнение, что вопрос следует понимать как «прямо в репозитории с проектом».
Если брать этот вопрос, то на него однозначно я ответить не могу, однако, склоняюсь к мысли, что можно и хранить, так как единственный контраргумент по сути — это размер репозитория, но для меня это не критично. А на девелоперскую и сборочную машину все равно весь этот объем тащить надо для сборки.
> Стоит ли хранить содержимое папки vendor в наших репозиториях?
Для меня наш репозиторий — это все то, что находится под моим управлением, включая условные svn.company.com, git.company.com, files.company.com, pkg.company.com и другие варианты. Гитхаб и репозитории вендоров по этому определению не наши.
Да, в дальнейшем было уточнение, что вопрос следует понимать как «прямо в репозитории с проектом».
Если брать этот вопрос, то на него однозначно я ответить не могу, однако, склоняюсь к мысли, что можно и хранить, так как единственный контраргумент по сути — это размер репозитория, но для меня это не критично. А на девелоперскую и сборочную машину все равно весь этот объем тащить надо для сборки.
Зачем вам на девелоперскую машину тащить iso-образы сборочных ОСей?
Ох! Конечно же все, что написано во втором абзаце моего предыдущего комментария относится только к зависимостям вида библиотеки и подобное (в папке vendor традиционно хранятся библиотеки).
Вот мы и возвращаемся к вопросу: Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Так в том то и дело, что храню!
Не путайте техническое разбиение инфраструктуры на репозитории, сабмодули и прочее с организационной стороной. С организационной точки зрения в моем репозитории есть и компиляторы.
Не путайте техническое разбиение инфраструктуры на репозитории, сабмодули и прочее с организационной стороной. С организационной точки зрения в моем репозитории есть и компиляторы.
Ок, я спрошу по другому: Почему же вы не храните в репозитории (проекта который пишите) компилятор того языка, который вы используете (iso-образы ОСей)?
Это разный уровень объектов. Инфраструктура компиляции и код проекта — это слабосвязанные между собой вещи, а код и библиотеки — сильно связанные.
Как это слабосвязанные? А если завтра, внезапно, язык на котором вы будите писать возьмет да удалится отовсюду, вы же не сможете задеплоить свой проект, как не сможете это сделать при отсутствии одной из библиотек. Так в чем разница? И то и другое нужно для успешной работы проекта.
Исчезновение библиотек я видел (например, поищите исходники PathScale и библиотек, которые они выкладывали на гитхаб и которые потом исчезли). Исчезновение всего линукса слишком маловероятно. Это во первых.
Во вторых, мой софт использует конкретную версию конкретной библиотеки, ее имеет смысл положить рядом. Компилируется же он в трех десятках окружений гарантированно и я не знаю в скольки еще линуксах скорее всего. Их не имеет смысла держать совсем рядом, при этом, как я уже писал выше, все компоненты окружений и сборки сборочных виртуальных машин аккуратно сложены в отдельном каталоге на файловом сервере.
Во вторых, мой софт использует конкретную версию конкретной библиотеки, ее имеет смысл положить рядом. Компилируется же он в трех десятках окружений гарантированно и я не знаю в скольки еще линуксах скорее всего. Их не имеет смысла держать совсем рядом, при этом, как я уже писал выше, все компоненты окружений и сборки сборочных виртуальных машин аккуратно сложены в отдельном каталоге на файловом сервере.
github.com/pathscale?
А если было бы вероятно, вы бы залили линуху в репозиторий своего проекта?
Исчезновение всего линукса слишком маловероятно
А если было бы вероятно, вы бы залили линуху в репозиторий своего проекта?
Имхо, исчезновение Гитхаба более вероятно чем исчезновение Линукса.
Скажите, пожалуйста, Вы читать умеете?
Для защиты от проблем с линуксом и интернетом у меня линуксы сложены в отдельный репозиторий на файловом сервере. Прочитайте уже перевод слово репозиторий, чтобы перестать ассоциировать его исключительно с системами управления версиями.
Еще раз повторюсь, что в проект имеет смысл складывать сильно связанные компоненты. Слабо связанные имеет смысл хранить, но не в проекте. Тот факт, что свой проект, который я сейчас подразумеваю собирается более чем в 30 окружениях, то каждое отдельное окружение слабо связано с проектом.
Библиотека же может использоваться только конкретной протестированной версии, так как ABI-совместимость и все такое — это сильно связанная компонента.
> github.com/pathscale?
Там есть исходники компилятора, который они выкладывали?
Оно было здесь: http://www.path64.org/ и https://github.com/path64, но исчезло и сылки с path64.org теперь ведут в никуда (например, github.com/path64/compiler).
Для защиты от проблем с линуксом и интернетом у меня линуксы сложены в отдельный репозиторий на файловом сервере. Прочитайте уже перевод слово репозиторий, чтобы перестать ассоциировать его исключительно с системами управления версиями.
Еще раз повторюсь, что в проект имеет смысл складывать сильно связанные компоненты. Слабо связанные имеет смысл хранить, но не в проекте. Тот факт, что свой проект, который я сейчас подразумеваю собирается более чем в 30 окружениях, то каждое отдельное окружение слабо связано с проектом.
Библиотека же может использоваться только конкретной протестированной версии, так как ABI-совместимость и все такое — это сильно связанная компонента.
> github.com/pathscale?
Там есть исходники компилятора, который они выкладывали?
Оно было здесь: http://www.path64.org/ и https://github.com/path64, но исчезло и сылки с path64.org теперь ведут в никуда (например, github.com/path64/compiler).
Скажите, пожалуйста, Вы читать умеете?
Просто вы не улавливаете мою иронию.
Слабо связанные имеет смысл хранить, но не в проекте
При отсутствии библиотеки вам нужно будет переписать часть проекта, а при отсутствии интерпретатора/компилятора — весь проект. Так где же тут слабая связь?
Библиотека же может использоваться только...
composer.lock вас спасет.
Для защиты от проблем с линуксом и интернетом у меня линуксы сложены в отдельный репозиторий на файловом сервере
Что мешает сложить туда же ваши зависимости?
> Просто вы не улавливаете мою иронию.
Это не похоже на иронию. Это похоже исключительно на глупость, уж простите меня за резкость.
> При отсутствии библиотеки вам нужно будет переписать часть проекта, а при отсутствии интерпретатора/компилятора — весь проект. Так где же тут слабая связь?
При отсутствии, например, Boost проект будет проще переписать с нуля или написать свой аналог буста.
А что касается компиляторов, то какого из 5 разных от 5 разных вендоров? Или всех сразу?
> Что мешает сложить туда же ваши зависимости?
Удобство использования. Один git clone/svn checkout и с проектом можно работать, а с composer придется выполнять дополнительные действия.
Это не похоже на иронию. Это похоже исключительно на глупость, уж простите меня за резкость.
> При отсутствии библиотеки вам нужно будет переписать часть проекта, а при отсутствии интерпретатора/компилятора — весь проект. Так где же тут слабая связь?
При отсутствии, например, Boost проект будет проще переписать с нуля или написать свой аналог буста.
А что касается компиляторов, то какого из 5 разных от 5 разных вендоров? Или всех сразу?
> Что мешает сложить туда же ваши зависимости?
Удобство использования. Один git clone/svn checkout и с проектом можно работать, а с composer придется выполнять дополнительные действия.
Это не похоже на иронию. Это похоже исключительно на глупость, уж простите меня за резкость.
Да вы меня не обидете, можете не стесняться высказываний )
При отсутствии, например, Boost проект будет проще переписать с нуля или написать свой аналог буста.
А что касается компиляторов, то какого из 5 разных от 5 разных вендоров? Или всех сразу?
Ну судя по вашей логике, нужно все сразу.
Удобство использования
А представьте как будет удобно, если вы зальете в проект сразу весь iso-образ ОСи с накатанным на нее проектом и всеми зависимости. Клац одну кнопку и у вас готовый к работе сервер )
Один git clone/svn checkout и с проектом можно работать, а с composer придется выполнять дополнительные действия
У вас composer перерабатывает и вы не хотите платить ему сверхурочные?
> Ну судя по вашей логике, нужно все сразу.
Ну раз все сразу, то в случае одновременного исчезновения Intel, Microsoft, GNU FSF и Apple, я думаю мне нужно будет искать другую отрасль (скорее всего земледелие), а не думать о том, что будет с моими проектами.
С библиотеками же все проще. Наглядный пример такого исчезновения я Вам привел (с гитхаба кстати).
> А представьте как будет удобно, если вы зальете в проект сразу весь iso-образ ОСи с накатанным на нее проектом и всеми зависимости. Клац одну кнопку и у вас готовый к работе сервер )
И это тоже есть. Все готовые образы виртуальных машин и докер-контейнеры сложены в файловом репозитории. Да, можно довести до одного клика, но в условиях множественных окружений это не имеет смысла на машине разработчика, а на билд-сервере все собирается в один клик на всех окружениях, там это имеет смысл.
> У вас composer перерабатывает и вы не хотите платить ему сверхурочные?
У меня очень ограниченный composer, так как Web-интерфейсы занимают меньшую часть моего времени.
Но даже в случае с composer я предпочитаю не перерабатывать сам и упрощать сервисные задачи. Лишние N Мб зависимостей в репозитории меня при этом не пугают, тем более, что их обновления идут в отдельных коммитах и не замусоривают историю.
Ну раз все сразу, то в случае одновременного исчезновения Intel, Microsoft, GNU FSF и Apple, я думаю мне нужно будет искать другую отрасль (скорее всего земледелие), а не думать о том, что будет с моими проектами.
С библиотеками же все проще. Наглядный пример такого исчезновения я Вам привел (с гитхаба кстати).
> А представьте как будет удобно, если вы зальете в проект сразу весь iso-образ ОСи с накатанным на нее проектом и всеми зависимости. Клац одну кнопку и у вас готовый к работе сервер )
И это тоже есть. Все готовые образы виртуальных машин и докер-контейнеры сложены в файловом репозитории. Да, можно довести до одного клика, но в условиях множественных окружений это не имеет смысла на машине разработчика, а на билд-сервере все собирается в один клик на всех окружениях, там это имеет смысл.
> У вас composer перерабатывает и вы не хотите платить ему сверхурочные?
У меня очень ограниченный composer, так как Web-интерфейсы занимают меньшую часть моего времени.
Но даже в случае с composer я предпочитаю не перерабатывать сам и упрощать сервисные задачи. Лишние N Мб зависимостей в репозитории меня при этом не пугают, тем более, что их обновления идут в отдельных коммитах и не замусоривают историю.
Потому что компиляторы не кроссплатформенные, да ещё и требуют зачастую в качестве зависимостей системные библиотеки. Была бы возможность — хранил бы рядом. Вот, например, субд OrientDB очень удобно хранить прямо в репе ибо она написана на яве и не требует установки.
вообще-то для инфраструктуры и окружения уже придуманы контейнеры, которые как раз таки и занимаются тем что содержат в себе все необходимое окружение. Но даже в этом случае (например если мы используем docker в качестве обертки над контейнерами) в git мы будем хранить только Dockerfile а не билды и прочий шлак. Собранный образ хранится в отдельном репозитории.
Я разве это оспариваю? Разговоры про компиляторы и ОСи пошли из-за боязни населения внезапно потерять доступ к чему то важному. Народ использует систему версионного контроля как резервное хранилище.
Я больше к аналогии Dockerfile как composer.json, что это так же инструкция как собрать зависимости проекта, а точнее окружение. Но само окружение никто не хранит, хранят только билды для деплоя.
Случаев, когда реально терялся компилятор или ОС я что-то припомнить не могу. С библиотеками же такое происходит и люди видимо с этим сталкивались. Даже если теряется не сама библиотека, может исчезнуть из апстрима ее старая версия, которая для тестов старой версии ПО потребуется или еще для чего-то подобного.
> Народ использует систему версионного контроля как резервное хранилище.
А почему версии библиотек не должны отслеживаться системами версионного контроля?
Наверное даже спрошу так, почему версия библиотеки в Вашем понимании — это только строка вида 1.2.3?
Вы никогда не патчили библиотеки, не бекпортировали в них изменения из аптрима без обновления всей библиотеки для сохранения ABI/API? По всем этим причинам для меня версии библиотек это не только цифры, но и весь ее код, который должен как минимум логически храниться или быть доступным в репозитории проекта.
> Народ использует систему версионного контроля как резервное хранилище.
А почему версии библиотек не должны отслеживаться системами версионного контроля?
Наверное даже спрошу так, почему версия библиотеки в Вашем понимании — это только строка вида 1.2.3?
Вы никогда не патчили библиотеки, не бекпортировали в них изменения из аптрима без обновления всей библиотеки для сохранения ABI/API? По всем этим причинам для меня версии библиотек это не только цифры, но и весь ее код, который должен как минимум логически храниться или быть доступным в репозитории проекта.
Вы никогда не патчили библиотеки
fork, патчим, делаем pull request. Только так. В composer.json можно заменить репозиторий на свой пока pull request на рассмотрении.
Если только так, значит Вам не критична стабильность API/ABI используемых библиотек, раз Вы можете позволить себе постоянно переходить на новые версии без бекпортирования исправлений и патчинга багов.
fork-patch-pull-request — это хорошо и правильно, но исправления войдут только в новую версию, которая может быть несовместима с используемой Вами и Вам придется все делать руками для своей версии.
P.S. Я если что не про Web и php сейчас, а про более общий случай.
fork-patch-pull-request — это хорошо и правильно, но исправления войдут только в новую версию, которая может быть несовместима с используемой Вами и Вам придется все делать руками для своей версии.
P.S. Я если что не про Web и php сейчас, а про более общий случай.
Вам не критична стабильность API/ABI используемых библиотек
Мне кажется это забота авторов библиотек. Я стараюсь не использовать трэш, а если и приходится — закрываю это оберткой так что изменения в библиотеке от версии к версии не особо страшны + покрыто тестами, так что если вдруг API меняется тесты сразу падают.
но исправления войдут только в новую версию, которая может быть несовместима с используемой Вами
Не используйте библиотеки не практикующие семвер, оборачивайте все нестабильное в стабильный интерфейс, и вообще все стороннее закрывать фасадами неплохая идея.
а про более общий случай.
мы тут обсуждаем composer, и да, даже в общем случае все примерно так же. Все плохо только в js мире где большинство пока не доросло до semver. Но и это думаю скоро пройдет.
> Мне кажется это забота авторов библиотек.
Клиенты не к авторам библиотеки придут, если у них что-то сломается, а к Вам.
> Я стараюсь не использовать трэш,
> Не используйте библиотеки не практикующие семвер,
Интересно Вы разработчиков стандарта С++ сейчас обозвали…
К сведению, среди разработчиков Boost есть немало разработчиков стандарта С++.
> закрываю это оберткой
> оборачивайте все нестабильное
Ну то есть полностью перепроектировать и переписать используемую библиотеку.
Посмотрите, как собираются RHEL или SLE и сколько патчей там есть к поставляемым библиотекам и приложениям. Даже если совместимость необходимо поддерживать не 10 лет, а всего год, то применяемые ими методики бекпортирования и багфиксинга придется применять и вам…
Клиенты не к авторам библиотеки придут, если у них что-то сломается, а к Вам.
> Я стараюсь не использовать трэш,
> Не используйте библиотеки не практикующие семвер,
Интересно Вы разработчиков стандарта С++ сейчас обозвали…
К сведению, среди разработчиков Boost есть немало разработчиков стандарта С++.
> закрываю это оберткой
> оборачивайте все нестабильное
Ну то есть полностью перепроектировать и переписать используемую библиотеку.
Посмотрите, как собираются RHEL или SLE и сколько патчей там есть к поставляемым библиотекам и приложениям. Даже если совместимость необходимо поддерживать не 10 лет, а всего год, то применяемые ими методики бекпортирования и багфиксинга придется применять и вам…
Ну то есть полностью перепроектировать и переписать используемую библиотеку.
Нет, просто уже лет 20-30 есть довольно удобная идея, не завязывать свое приложение на инфраструктуру. Если вы используете какую-то библиотеку в контексте какой-то задачи — заверните ее в бумажку (фасад, интерфейс). Тогда изменения в инфраструктуре не будут влиять на приложение.
Даже если совместимость необходимо поддерживать не 10 лет, а всего год, то применяемые ими методики бекпортирования и багфиксинга придется применять и вам…
И вот вы сначала перепрыгнули на C++ (у которого традиция хранить зависимости хотя бы через сабмодули идет корнями к проблеме отсутствия вменяемого менеджера пакетов), а теперь вообще на дистрибьютивы linux. Я теряю нить логической связи обсуждаемой проблемы.
> Нет, просто
См. выше про фреймворки, которые тоже библиотеки по сути. Завернуть фреймворк в обертку — это по сути написать свой.
> И вот вы сначала перепрыгнули
Смотрим начало этой ветки:
> Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Вы знаете компиляторы для PHP? Я нет (HHVM не совсем то). И далее по ветке.
См. выше про фреймворки, которые тоже библиотеки по сути. Завернуть фреймворк в обертку — это по сути написать свой.
> И вот вы сначала перепрыгнули
Смотрим начало этой ветки:
> Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Вы знаете компиляторы для PHP? Я нет (HHVM не совсем то). И далее по ветке.
Завернуть фреймворк в обертку — это по сути написать свой.
Вы сами сказали что фреймворк это набор библиотек по сути, так что нам не составляет труда завернуть то что нам нужно в интерфейс. Ну и опять же, что бы небыло недопонимания. Фреймворк состоит из кучи библиотек, но большинство из них это реализация интфрейса приложения (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 что бы не париться больше и ускорить работу.
> так что нам не составляет труда завернуть то что нам нужно в интерфейс
Чтобы не быть голословным, предложите, пожалуйста, вариант оберток для любой библиотеки из Boost. А потом, скажите, что Вы будете делать, когда после стабилизации и усовершенствования библиотека из Boost попадет в стандарт. Будете поддерживать обертки поверх стандарта (но зачем)? Или с печальным видом избавляться от них переходя обратно на API, который был практически изначально?
> Вы же выбрали язык, где нет нормального менеджера пакетов, потому там царит хаос
Я выбрал тот язык, который для моих задач подходит наиболее хорошо. Скажу даже больше, где-то рядом все еще живее всех живых Fortran (и приносит разработчикам компиляторов денег не меньше чем С++, кстати).
> стараются использовать ссылки на репозитории, сабмодули и прочее.
Перечитайте, пожалуйста, всю ветку. Возможно, тогда Вы увидите, что я про это практически с самого начала говорю.
> выгоднее использовать средства аля Docker
И об этом я тоже писал чуть выше…
К сожалению еще не для всех продуктивных задач докер подходит, но работы в этом отношении идут и перспективы меня радуют.
Чтобы не быть голословным, предложите, пожалуйста, вариант оберток для любой библиотеки из Boost. А потом, скажите, что Вы будете делать, когда после стабилизации и усовершенствования библиотека из Boost попадет в стандарт. Будете поддерживать обертки поверх стандарта (но зачем)? Или с печальным видом избавляться от них переходя обратно на API, который был практически изначально?
> Вы же выбрали язык, где нет нормального менеджера пакетов, потому там царит хаос
Я выбрал тот язык, который для моих задач подходит наиболее хорошо. Скажу даже больше, где-то рядом все еще живее всех живых Fortran (и приносит разработчикам компиляторов денег не меньше чем С++, кстати).
> стараются использовать ссылки на репозитории, сабмодули и прочее.
Перечитайте, пожалуйста, всю ветку. Возможно, тогда Вы увидите, что я про это практически с самого начала говорю.
> выгоднее использовать средства аля Docker
И об этом я тоже писал чуть выше…
К сожалению еще не для всех продуктивных задач докер подходит, но работы в этом отношении идут и перспективы меня радуют.
предложите, пожалуйста, вариант оберток для любой библиотеки из Boost
Boost не надо оборачивать, но он же используется для чего-то? так вот это что-то и оборачивается. Ну и да, есть здравый смысл, так что перегибать палку уж не надо. Просто надо стараться изолировать код приложения (бизнес логика и т.д.) от сторонних библиотек и фреймворков. Главные то не они.
С C++ мне сложно предложить пример так как я ничего осбо на нем и не пишу.
Словом… я запутался немного с формулировками. Использование сабмодулей это все же не то же самое что «держать в репозитории». В такой же трактове с этим проблем нет.
> так вот это что-то и оборачивается… Просто надо стараться изолировать код приложения (бизнес логика и т.д.)…
Так вот это что-то может быть нашим приложением. Boost очень низкоуровневая штука, чуть выше чем стандартная библиотека языка по сути. А как можно эффективно и со смыслом изолировать бизнес-логику, например, от контейнеров я не знаю.
Конечно, если под библиотеками понимать что-то более высокоуровневое, например, Qt для GUI, то в этом случае отделять бизнес-логику от собственно GUI вполне понятно как и необходимо.
Так вот это что-то может быть нашим приложением. Boost очень низкоуровневая штука, чуть выше чем стандартная библиотека языка по сути. А как можно эффективно и со смыслом изолировать бизнес-логику, например, от контейнеров я не знаю.
Конечно, если под библиотеками понимать что-то более высокоуровневое, например, Qt для GUI, то в этом случае отделять бизнес-логику от собственно GUI вполне понятно как и необходимо.
Просто надо стараться изолировать код приложения (бизнес логика и т.д.) от сторонних библиотек и фреймворков. Главные то не они.
И потому держать их в репозитории приложения нет никакого смысла :)
Заведите себе зеркало пакаджиста с репами.
А вы используете только библиотеки, которые не могут быть удалены никогда, ни при каких обстоятельствах?
Наедет какой-нибудь копираст и опа, вы не можете задеплоиться и начинаете судорожно пихать пропавшие из репозитория модули в свой репозиторий с кодом.
Наедет какой-нибудь копираст и опа, вы не можете задеплоиться и начинаете судорожно пихать пропавшие из репозитория модули в свой репозиторий с кодом.
А вы используете только библиотеки, которые не могут быть удалены никогда, ни при каких обстоятельствах?
Для интереса пробежался по зависимостям моего текущего проекта и могу с гордостью ответить — да
Наедет какой-нибудь копираст и опа, вы не можете задеплоиться и начинаете судорожно пихать пропавшие из репозитория модули в свой репозиторий с кодом
Зачем что то куда то пихать? Все зависимости я могу восстановить себе из локальной копии проекта, а если их еще и залить на корпаративный git репозиторий и поправить composer.json, то все сразу заработает.
Вы либо врёте, либо заблуждаетесь. Ни то, ни другое не делает вам чести.
Не важно куда вы будете их пихать. Важно то, что вы узнаете о проблеме лишь при деплое. Не говоря уж о том, что вам может потребоваться «размораживать» проект, имея лишь репу с исходниками на руках.
Вот вы можете назвать хоть одну причину не хранить зависимости в репозитории, кроме как незначительное увеличение его объёма? Эта причина правда стоит того, чтобы придумывать сложные схемы с локами версий, локальными зеркалами репозиториев на сборочном сервере, терпеть медленную сборку, переключение веток и bisect, шаманством для выяснения что именно поменялось в коде зависимостей? Ну вот честно, правда оно того стоит?
Не важно куда вы будете их пихать. Важно то, что вы узнаете о проблеме лишь при деплое. Не говоря уж о том, что вам может потребоваться «размораживать» проект, имея лишь репу с исходниками на руках.
Вот вы можете назвать хоть одну причину не хранить зависимости в репозитории, кроме как незначительное увеличение его объёма? Эта причина правда стоит того, чтобы придумывать сложные схемы с локами версий, локальными зеркалами репозиториев на сборочном сервере, терпеть медленную сборку, переключение веток и bisect, шаманством для выяснения что именно поменялось в коде зависимостей? Ну вот честно, правда оно того стоит?
Вы либо врёте, либо заблуждаетесь. Ни то, ни другое не делает вам чести.
С чего же такие выводы, что на их основании вы меня уже начали обвинять? )
Не важно куда вы будете их пихать
Так важна ли возможность непрерывного деплоя или не важна?
Вот вы можете назвать хоть одну причину не хранить зависимости в репозитории, кроме как незначительное увеличение его объёма?
Да, уже отвечал на этот вопрос немного выше.
Ну вот честно, правда оно того стоит?
Стоит ли пользоваться системами сборки, деплоя, автоматического тестирования, контроля версий, контроля задач, когда можно пойти более простым путем и не пользоваться этим?
Вот вы можете назвать хоть одну причину не хранить зависимости в репозитории, кроме как незначительное увеличение его объёма?
шаманством для выяснения что именно поменялось в коде зависимостей?
Основная причина: подавляющее большинство времени при работе над проектом я не хочу знать, что поменялось в коде зависимостей — вполне достаточно диффа composer.json для того, чтобы знать как коллеги поменяли зависимости, даже диффы composer.lock раздражают в коммитах, но это меньшее зло чем что не хранить версии зависимостей вообще, чем что хранить не только «номера» версий, но и их самих.
Кирпич вам на голову может прилететь с гораздо большей вероятностью, и последствия куда фатальнее. Вы наверх всегда смотрите, когда рядом с высотными домами ходите?
Хранить нельзя. Чтобы зафиксировать версии, вам нужно хранить composer.lock в репозитории.
Если вы боитесь, что будут недоступны какие-то проекты и пакеты, воспользуйтесь проксированием packagist.org с помощью разных систем, например Satis
Если вы боитесь, что будут недоступны какие-то проекты и пакеты, воспользуйтесь проксированием packagist.org с помощью разных систем, например Satis
Хранить можно. Чтобы не выстраивать целую архитектуру в виде проксирования с помощью разных систем, добавляя лишние звенья, достаточно просто хранить используемый сторонний открытый код где-то рядышком.
где-то рядышкомтак ведь это ключевое замечание. Обсуждение подразумевает хранение вендорского кода прямо в репозитории с проектом. В одном репозитории.
Сатис работает на php в кроне, а отдаёт статику nginx'ом, никаких заморотов, зато полное версионирование ваших пакетов. Если нужно будет поставить предыдущию версию, она всегда будет в сатис.
Прямо в репозитории хранить нельзя, т.к. это лишний код в репозитории, который по факту не нужен. Если очень хочется, можете попробовать хранить как сабмодуль, но это тоже идея не самая хорошая.
Прямо в репозитории хранить нельзя, т.к. это лишний код в репозитории, который по факту не нужен. Если очень хочется, можете попробовать хранить как сабмодуль, но это тоже идея не самая хорошая.
C сатисом не удобно то, что добавлять пакеты нужно руками. Если хочется комфортного и прозрачного проксирования то лучше Toran Proxy — коммерческий аналог Satis от автора composer. Он автоматически умеет кешировать и обновлять пакеты, если его прописать как замену packinst.org. Он в таком случае всегда стягивает себе отсутствующие пакеты себе и отдает вам их из локального хранилища.
У меня тоже была мысль привести его в качестве примера. Вопрос только в том, что он платный, а значит обосновать придется хорошенечко. Пробовали его в своих проектах?
Да, практически с момента его выхода. До этого использовали сатис и для внутренних пакетов и для наиболее часто используемых важных внешних. Был какой-то период когда у нас постоянно были проблемы то с доступностью гитхаба, откуда тянулось пара наших открытых пакетов, потом был период с недоступностью или лагами самого сайта packagist.org. Это регулярно разбавлялось проблемами нашего основного провайдера в офисе. Торан реальная палочка выручалочка — всё равно есть интернет, нет интернета и что сейчас доступно, а что нет, всё стянется из локальной копии на его сервере. В целом — очень рекомендую.
Satis — он тоже от автора Composer, кстати.
Не знаю, возможно ли такое на packagist-е, но на rubygems-е у меня один раз такое было, что файл lock ссылался на gem, которые был yanked из репозитроия, благодаря чему грузилась следующая версия gem-а, которая не была совместима с приложением. В результате gem пришлось вытаскиваить со старого компа одного из девелоперов, где он чудом сохранился. Поэтому я однозначно за хранение копий всех зависимостей в репозитории проекта. А в случае Ruby так еще и всю директорию с Ruby лучше зачекинить.
Для жесткой фиксации есть composer.lock )))
После прочтения комментариев, очень хочется цитировать Лаврова, но кролик очень вежливый, поэтому не будет.
Есть ноут, на котором я пишу код и где-то далеко есть некая песочница, куда этот код синхронизируется и где я смотрю результат, отлаживаю (отделяю код от лажи :)).
Все начинается с того, что я клонирую себе репу проекта.
Если вендорские библиотеки лежат в репе, я сразу их получаю.
Если библиотек там нет, то
Все начинается с того, что я клонирую себе репу проекта.
Если вендорские библиотеки лежат в репе, я сразу их получаю.
- У меня в IDE сразу работает навигация по классам этих библиотек.
- Я работаю с одним инструментом — git.
- Код (а не мета-информация) библиотеки фиксирован, и мне наплевать, что случится с репой самой библиотеки, даже если им вздумается ее удалить или внеси изменения в текущую версию задним числом, и все сломать.
Если библиотек там нет, то
- Чтоб работала навигация IDE мне надо дополнительно поставить себе на ноут PHP и композер, и еще не забаывать его запускать в случае обновлений.
- Я завишу от людей, которых не знаю. И если версию библиотеки можно зафиксировать в composer.lock, то как зафиксировать желание ее разрабочиков что-то изменить в ее коде без подъема ее версии?
Я доверяю библиотеке на некоторый момент ее скачивания, когда я это дело контролирую. После этого я должен доверять другим людям, потому что каждый раз скачивать ее будет композер без моего участия.
Да, можно использовать свои форки, свои packagistы, какой-то проксирующий софт. Но едва ли это более удобно, чем видеть коммиты с апдейтом библиотек в своей репе. (Причем, в виде бонуса видеть что именно там поменялось без допольнительных diff-утилит.)
Не могу согласиться, к сожалению: при маленьком изменении в вашем коде с большим изменением (например — мажорная версия) в вендорском коде, вы ревьюер в diff-е ничего путного не увидит. Сам change вашего кода может быть вообще в этой куче потерян.
Обновление бибилотек надо делать отдельными коммитами. Всего лишь немного дисциплины при обращении с репой.
Ну либо я что-то упускаю из виду.
Ну либо я что-то упускаю из виду.
"Я просто оставлю это здесь", в теме в которой меня заминусовали за оправдание подобного подхода ;)
https://habrahabr.ru/post/280206/
https://habrahabr.ru/post/280206/
Решение команды разработчиков ESLint было довольно радикальным, но вполне рабочим. Они решили опубликовать пакет ESLint со всеми зависимостями. То есть скачивая архив ESLint, утилита npm скачает также и весь рабочий node_modules для необходимой версии ESLint.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Composer — the right way