Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
Я, со своей стороны, придерживаюсь мнения, что все, что нужно для сборки проекта должно храниться в репозитории.
Аргументы сторон следующие.
Против NPR:
После клонирования репозитория у меня уже самодостаточная копия всего окружения и соединения с Интернетом мне не требуется
Я всегда могу выполнить hg update до любой версии и все зависимости гарантированно будут на месте
От билд-сервера не требуется ничего особенного (яркий пример: даже TFS нужно настраивать отдельно)
Не все зависимости и сторонние библиотеки есть в NuGet Ненадежная работа NPR, особенно в случаях, когда hg update'ишся между древними и новыми версиями
Местами интеграция VS и NuGet сломана (игнорируется nuget.config, например)
За NPR:
Бинарники могут сильно раздувать размер репозитория
С точки зрения разработчика всё очень просто и "Just Works"
Microsoft рекомендует
Честно сказать, не самые убедительные доводы. У кого какое мнение на этот счет?
HgLab: Mercurial Server and Repository Management for Windows
Re: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
Н>Я, со своей стороны, придерживаюсь мнения, что все, что нужно для сборки проекта должно храниться в репозитории.
Однозначно package restore. Есть очень негативный опыт чистки Git-репозитория после того, как в него на протяжении года складывали бинарные зависимости. Репозиторий разросся до нескольких гигабайт и чудовищно тормозил. Настолько, что git pull стал занимать десятки минут после очередного обновления тех самых зависимостей. Наверняка можно было как-то "подкрутить", но это уже костыль. Если есть какие-то причины не доверять официальному репозиторию NuGet, свой поднимается за 2 клика мышкой.
Re[2]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, andyag, Вы писали:
A>Однозначно package restore. Есть очень негативный опыт чистки Git-репозитория после того, как в него на протяжении года складывали бинарные зависимости. Репозиторий разросся до нескольких гигабайт и чудовищно тормозил. Настолько, что git pull стал занимать десятки минут после очередного обновления тех самых зависимостей.
Вот перед глазами пример -- проекту 2 года, 5 Мб исходников, объем довольно интенсивно обновляемой директории /lib -- 302 Мб, она же в репозитории -- 33 Мб, весь репозиторий -- 92 Мб. Может быть, не самый большой проект, но и распухания репы тоже не ощущается.
A>Если есть какие-то причины не доверять официальному репозиторию NuGet, свой поднимается за 2 клика мышкой.
Вопрос не в недоверии, а в том, что решение с NuGet'ом -- довольно хрупкое и привносит гораздо большие проблемы, чем простое распухание репозитория.
HgLab: Mercurial Server and Repository Management for Windows
Re[3]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, andyag, Вы писали:
A>>Однозначно package restore. Есть очень негативный опыт чистки Git-репозитория после того, как в него на протяжении года складывали бинарные зависимости. Репозиторий разросся до нескольких гигабайт и чудовищно тормозил. Настолько, что git pull стал занимать десятки минут после очередного обновления тех самых зависимостей.
Н>Вот перед глазами пример -- проекту 2 года, 5 Мб исходников, объем довольно интенсивно обновляемой директории /lib -- 302 Мб, она же в репозитории -- 33 Мб, весь репозиторий -- 92 Мб. Может быть, не самый большой проект, но и распухания репы тоже не ощущается.
Видимо Mercurial более непробиваемый в этом сценарии. Не возьмусь тогда предсказывать, когда у вас случится конец света. В любом случае, бест прэктис — разделять бинарные зависимости и код. В .NET NuGet появился сравнительно недавно, а в той же Java, например, аналогичным инструментам (Maven) уже сто лет в обед, поэтому желания хранить библиотеки вместе с кодом обычно не возникает. Аналогичные подходы используются ещё в куче случаев: у серверного NodeJS есть NPM, у клиентского JS есть Bower, у Ruby есть Gems, у Python — pip. С другой стороны в C++, например, приходится хранить библиотеки рядом с кодом, т.к. у них вообще систем управления зависимостями нет.
A>>Если есть какие-то причины не доверять официальному репозиторию NuGet, свой поднимается за 2 клика мышкой. Н>Вопрос не в недоверии, а в том, что решение с NuGet'ом -- довольно хрупкое и привносит гораздо большие проблемы, чем простое распухание репозитория.
А опишите в чём по-вашему хрупкость. ИМХО, единственная ситуация, когда всё пропало — это желание поработать с новым проектом (для которого restore ещё не запускался) при отсутствие интернета. Но даже к таким ситуациям можно подготовиться подняв локальный NuGet и сложив туда всё что нужно.
Re[4]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, andyag, Вы писали:
A>А опишите в чём по-вашему хрупкость.
Банальное отсутствие интернета -- и оппа! Это самая тривиальная проблема, но все же стоит упомянуть.
Я не могу быть до конца уверенным, что в -- нашем или в "публичном" -- NuGet-сервере всегда будут присутствовать все когда-либо использованные в проекте версии библиотек.
Нет гарантии, что пакеты не сервере не будут изменены "задним числом".
Нужны дополнительные нетривиальные приседания при конфигурировании билд-серверов
Опять же, не всё есть в NuGet'ах
Не работает Restore для Content File'ов ( https://nuget.codeplex.com/workitem/2094 )
Связка Azure и Private Feeds не работает от слова вообще -- некуда пхать логин и пароль
Private Feed'ы могут требовать наличия доступа в корпоративную сеть
Плюс, для работы Package Restore рекомендуют держать nuget.exe в репозитории с проектом, что как-то странно на фоне заветов "Нет бинарникам в репе!"
HgLab: Mercurial Server and Repository Management for Windows
Re[5]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, andyag, Вы писали:
A>>А опишите в чём по-вашему хрупкость.
Н> Банальное отсутствие интернета -- и оппа! Это самая тривиальная проблема, но все же стоит упомянуть.
Интернет нужен только 1 раз — когда делается собственно restore. После restore интернет не нужен.
Н> Я не могу быть до конца уверенным, что в -- нашем или в "публичном" -- NuGet-сервере всегда будут присутствовать все когда-либо использованные в проекте версии библиотек. Н> Нет гарантии, что пакеты не сервере не будут изменены "задним числом".
Вы уже подписались на Microsoft, завязавшись на дотнет. Почему именно теперь такие сомнения возникают?
Н> Нужны дополнительные нетривиальные приседания при конфигурировании билд-серверов
В Тимсити package restore настраивается в 2 клика мышкой без всяких плясок с бубном.
Н> Опять же, не всё есть в NuGet'ах
В этом случае хорошим решением будет поднять свой NuGet и самостоятельно сложить туда нужные штуки. Свои пакеты делаются за 15 минут гугла и ещё 10 минут экспериментов.
Н> Не работает Restore для Content File'ов ( https://nuget.codeplex.com/workitem/2094 )
Это проблемы локального масштаба. Если они помешают вашей работе, нужно либо искать обходные пути, либо подождать пока починят. Вообще я пока не встречал инструментов, в которых не было бы багов.
Н> Связка Azure и Private Feeds не работает от слова вообще -- некуда пхать логин и пароль
Здесь не могу ничего сказать — видимо какой-то конкретный сценарий, с которым я не сталкивался.
Н> Private Feed'ы могут требовать наличия доступа в корпоративную сеть
Серверная часть NuGet — это обычный веб-сервис, поэтому как настроите права доступа, так и будет работать. Если вы смотрите только на официальный подход (это где IIS и возня руками), советую ещё посмотреть на Nexus — у нас замечательно работает.
Н> Плюс, для работы Package Restore рекомендуют держать nuget.exe в репозитории с проектом, что как-то странно на фоне заветов "Нет бинарникам в репе!"
Это один единственный бинарник очень маленького размера, который будет меняться не чаще пары раз в год. В Java один из инструментов сборки (Gradle) в приказном порядке рекомендую класть в репозиторий. Но он тоже маленький и проблем не вызывает. Утверждение "Нет бинарникам в репе!" посвящено не тому, что их нельзя туда класть, а тому, что нужно осознавать к чему это может привести. Хранить 1 мегабайт — скорее всего никогда не станет проблемой. Хранить пачку нативных DLL общим объёмом 200 мегабайт и раз в день их все обновлять — скорее всего станет проблемой очень скоро.
28.12.14 23:16: Удалено модератором из 'Философия программирования'.
30.12.14 18:46: Восстановлено модератором.
Re[6]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, andyag, Вы писали:
Н>Банальное отсутствие интернета -- и оппа! Это самая тривиальная проблема, но все же стоит упомянуть. A>Интернет нужен только 1 раз — когда делается собственно restore. После restore интернет не нужен.
А так же при каждом hg update, когда меняются версии зависимостей. Нечасто, но тем не менее.
Н>>Я не могу быть до конца уверенным, что в -- нашем или в "публичном" -- NuGet-сервере всегда будут присутствовать все когда-либо использованные в проекте версии библиотек. Н>>Нет гарантии, что пакеты не сервере не будут изменены "задним числом". A>Вы уже подписались на Microsoft, завязавшись на дотнет. Почему именно теперь такие сомнения возникают?
Не подменяйте предмет. Вероятность того, что по тем или иным причинам что-то не то станет с пакетами -- ненулевая. Могут отъехать DLL'ки, с Symbol Server'
а могут пропасть PDB-файлы -- может многое произойти.
Н>>Нужны дополнительные нетривиальные приседания при конфигурировании билд-серверов A>В Тимсити package restore настраивается в 2 клика мышкой без всяких плясок с бубном.
Да, там попроще. В TFS же тоска-печаль.
Н>>Опять же, не всё есть в NuGet'ах A>В этом случае хорошим решением будет поднять свой NuGet и самостоятельно сложить туда нужные штуки. Свои пакеты делаются за 15 минут гугла и ещё 10 минут экспериментов.
См. ниже. И в некоторых сов на глобус NuGet никак не натянуть
Н>>Private Feed'ы могут требовать наличия доступа в корпоративную сеть A>Серверная часть NuGet — это обычный веб-сервис, поэтому как настроите права доступа, так и будет работать. Если вы смотрите только на официальный подход (это где IIS и возня руками), советую ещё посмотреть на Nexus — у нас замечательно работает.
Например, сервер NuGet доступен только извне. Требуется VPN.
HgLab: Mercurial Server and Repository Management for Windows
Re: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
А я все бинарники всегда кладу в git. А про NuGet Package Restore узнал только сейчас.
Кодом людям нужно помогать!
Re: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
Я абсолютно всё нужное храню в своей системе контроля версий. Код, бинарники, ресурсы — всё.
Re[2]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, andyag, Вы писали:
A>Однозначно package restore. Есть очень негативный опыт чистки Git-репозитория после того, как в него на протяжении года складывали бинарные зависимости. Репозиторий разросся до нескольких гигабайт и чудовищно тормозил.
Это потому что гит таки убог.
Re[3]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, andyag, Вы писали:
A>>Однозначно package restore. Есть очень негативный опыт чистки Git-репозитория после того, как в него на протяжении года складывали бинарные зависимости. Репозиторий разросся до нескольких гигабайт и чудовищно тормозил. С>Это потому что гит таки убог.
А есть какой-то VCS, официально утверждающий, что хранение больших бинарных файлов для него не проблема, как и хранение маленьких текстовых?
Re[4]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Банальное отсутствие интернета -- и оппа!
Так без интернета ты и удалённый репозиторий не склонируешь. Если же у тебя центральный репозиторий содержится локально, то и папку с пакетами можно держать локально. Версионирование библиотек — специфическая, частная задача; не очень практично для её решения использовать инструменты версионирования общего назначения (мерджи, диффы, ветки, etc.)
Глаза у меня добрые, но рубашка — смирительная!
Re[5]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, andyag, Вы писали:
A>>А есть какой-то VCS, официально утверждающий, что хранение больших бинарных файлов для него не проблема, как и хранение маленьких текстовых?
ZEN>Да — CVS.
Вы используете CVS?
Re[7]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, andyag, Вы писали:
Н>>Банальное отсутствие интернета -- и оппа! Это самая тривиальная проблема, но все же стоит упомянуть. A>>Интернет нужен только 1 раз — когда делается собственно restore. После restore интернет не нужен. Н>А так же при каждом hg update, когда меняются версии зависимостей. Нечасто, но тем не менее.
Я не понимаю ваши доводы. Если вы можете скачать код, вы с таким же успехом можете и бинарные зависимости скачать в случае корпоративного/проектного NuGet репозитория. Если же код лежит где-то на BitBucket, а интернет кончился, проблемы начнутся ещё на этапе hg update
Опишите вашу ситуацию чуть более конкретно, очень может быть, что мои утверждения для вашего случая реально полный бред. Например какое-то закрытое предприятие, где один общий компьютер с доступом к интернет в DMZ.
Н>>>Я не могу быть до конца уверенным, что в -- нашем или в "публичном" -- NuGet-сервере всегда будут присутствовать все когда-либо использованные в проекте версии библиотек. Н>>>Нет гарантии, что пакеты не сервере не будут изменены "задним числом". A>>Вы уже подписались на Microsoft, завязавшись на дотнет. Почему именно теперь такие сомнения возникают? Н>Не подменяйте предмет. Вероятность того, что по тем или иным причинам что-то не то станет с пакетами -- ненулевая. Могут отъехать DLL'ки, с Symbol Server' Н>а могут пропасть PDB-файлы -- может многое произойти.
Ни в коем случае не пытался подменить предмет разговора. Дело в том, что когда вы делаете выбор в пользу какой-то платформы/языка, вы автоматически подписываетесь на существующие best practices. В ситуации с .NET ("в мире .NET"), когда вы хотите использовать сторонние библиотеки, вы используете NuGet. Это просто подход по умолчанию — со всеми рисками, плюсами и минусами. Если у вас есть причины не использовать подход по умолчанию, не используйте его. В этом случае непонятен смысл топика.
Н>>>Опять же, не всё есть в NuGet'ах A>>В этом случае хорошим решением будет поднять свой NuGet и самостоятельно сложить туда нужные штуки. Свои пакеты делаются за 15 минут гугла и ещё 10 минут экспериментов. Н>См. ниже. И в некоторых сов на глобус NuGet никак не натянуть
Сорри — не смог прочитать что вы написали.
Н>>>Private Feed'ы могут требовать наличия доступа в корпоративную сеть A>>Серверная часть NuGet — это обычный веб-сервис, поэтому как настроите права доступа, так и будет работать. Если вы смотрите только на официальный подход (это где IIS и возня руками), советую ещё посмотреть на Nexus — у нас замечательно работает. Н>Например, сервер NuGet доступен только извне. Требуется VPN.
Доступ к своему NuGet должен быть таким же, как доступ к репозиторию с кодом (опять же — по умолчанию, если нет причин делать иначе).
Re[6]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Возник у нас тут спор
У нас он решен компромиссно. Бинарные зависимости хранятся в виде nuget, исходный же код хранится в VCS: это и гибкое распределение трафика между серверами, и нормальный diff между ревизиями.
Н>Я, со своей стороны, придерживаюсь мнения, что все, что нужно для сборки проекта должно храниться в репозитории. Н>После клонирования репозитория у меня уже самодостаточная копия всего окружения и соединения с Интернетом мне не требуется
Мнение добротное для маленьких проектиков, и морально устаревшее в эпоху безлимита / интранетов.
Н>Я всегда могу выполнить hg update до любой версии и все зависимости гарантированно будут на месте
Иррелевантно.
Н>От билд-сервера не требуется ничего особенного (яркий пример: даже TFS нужно настраивать отдельно)
А вот в TeamCity интеграция с nuget изкаробки Что, конечно же не отменяет плясок с ТФС Тем не менее, тоже не аргумент ввиду того, что с минимальными (нет, серьезно!) усилиями выкачку бинарных зависимостей можно встроить в билдскрипт или проект.
Из практики: Package Restore бесполезен.
Н>Не все зависимости и сторонние библиотеки есть в NuGet
О_о Что мешает создать свои пакеты для своих проектов в своем (см. выше) репозитории?! Принципиальная опенсорсность проекта разве что?
Н>Ненадежная работа NPR, особенно в случаях, Н>когда hg update'ишся между древними и новыми версиями Н>Местами интеграция VS и NuGet сломана (игнорируется nuget.config, например)
Есть кой-какие глюки и с nuget, но не настолько регулярные и болезненные, чтобы стать аргументом "Против".
Из практики: интеграция вообще нафиг не нужна.
Н>Бинарники могут сильно раздувать размер репозитория
Этот аргумент будет недооценен теми, у кого в зависимостях не встречалось чего-нибудь типа дистрибудива Castle или там EL5 с исходниками.
Н>С точки зрения разработчика всё очень просто и "Just Works"
В целом так и есть.
Н>Microsoft рекомендует
Не аргумент
Н>Честно сказать, не самые убедительные доводы
Согласен, доводы были приведены совершенно неубедительные, и, скорее демонстрирующие недостаточное знание матчасти.
Re[3]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Вот перед глазами пример -- проекту 2 года, 5 Мб исходников, объем довольно интенсивно обновляемой директории /lib -- 302 Мб, она же в репозитории -- 33 Мб, весь репозиторий -- 92 Мб. Может быть, не самый большой проект, но и распухания репы тоже не ощущается.
Все-таки, ваш опыт не включает еще ничего, кроме маленьких проектиков
А вот у меня перед глазами одна компонента подсистемы одной из систем, в состоянии "до компиляции" весит что-то около гигабайта, из которых метров 100 — исходные коды...
Понятно, боюсь тогда, что мой посыл
не будет воспринят с должным пониманием, так как у нас с вами сильно разные "весовые категории".
Н>Вопрос не в недоверии, а в том, что решение с NuGet'ом -- довольно хрупкое и привносит гораздо большие проблемы, чем простое распухание репозитория.
Все-таки бенефиты nuget на мелких масштабах сложно оценить по достоинству.
