Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в 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 на мелких масштабах сложно оценить по достоинству.
Re[5]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Банальное отсутствие интернета -- и оппа! Это самая тривиальная проблема, но все же стоит упомянуть.
Маломальски коммерческие разработки, как правило, не привязываются к nuget.org. А отсутствие сети в масштабах офиса — это какая-то другая проблема, не nuget. Не аргумент.
Н>Я не могу быть до конца уверенным, что в -- нашем или в "публичном" -- NuGet-сервере всегда будут присутствовать все когда-либо использованные в проекте версии библиотек.
А с VCS, значит, такая уверенность есть? Короче, паранойя — не аргумент.
Н>Нет гарантии, что пакеты не сервере не будут изменены "задним числом".
Иррелевантно. Это никоим оброзом не проблема nuget.
Н>Нужны дополнительные нетривиальные приседания при конфигурировании билд-серверов
Нет, не нужны. И не балд-серверов, а билд-агентов, к слову.
Н>Опять же, не всё есть в NuGet'ах
Это снова какая-то другая проблема, не относящаяся к nuget. Отсутствие пакета в репозитории — это лишь следствие иной проблемы.
Н>Не работает Restore для Content File'ов ( https://nuget.codeplex.com/workitem/2094 )
Status: Closed
Н> Плюс, для работы Package Restore рекомендуют держать nuget.exe в репозитории с проектом
Рекомендуют != требуют. При минимальной прямоте рук разработчиков в коде проекта нет ничего лишнего и/или глобального.
Re[2]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Wolverrum, Вы писали:
Н>>Я всегда могу выполнить hg update до любой версии и все зависимости гарантированно будут на месте W>Иррелевантно.
Нет. В случае самодостаточного репозитория подобные гарантии у меня есть. В случае, когда требуется еще что-то извне -- всегда есть шанс, что что-то отвалится.
Н>>Не все зависимости и сторонние библиотеки есть в NuGet W>О_о Что мешает создать свои пакеты для своих проектов в своем (см. выше) репозитории?! Принципиальная опенсорсность проекта разве что?
Я уже приводил в качестве примера libgit2 и libgit2sharp, который нельзя было завернуть в NuGet-пакет потому, что он искал нативные DLL'ки не в тех местах, в которые NuGet их мог положить. Посему, не всё можно засунуть в NuGet.
HgLab: Mercurial Server and Repository Management for Windows
Re[6]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Wolverrum, Вы писали:
Н>>Я не могу быть до конца уверенным, что в -- нашем или в "публичном" -- NuGet-сервере всегда будут присутствовать все когда-либо использованные в проекте версии библиотек. W>А с VCS, значит, такая уверенность есть? Короче, паранойя — не аргумент.
В чем паранойя? Да, в случае с хранением зависимостей в VCS такая уверенность есть.
Н>>Нет гарантии, что пакеты не сервере не будут изменены "задним числом". W>Иррелевантно. Это никоим оброзом не проблема nuget.
Мы обсуждаем не NuGet как таковой, а Package Restore и "недержание" зависимостей в VCS. В случае с NPR такая проблема имеет место быть.
Н>>Нужны дополнительные нетривиальные приседания при конфигурировании билд-серверов W>Нет, не нужны. И не балд-серверов, а билд-агентов, к слову.
Ок, билд-агентов. И пятистраничная инструкция о том, как настроить TFS -- это "не нужны"?
Н>>Опять же, не всё есть в NuGet'ах W>Это снова какая-то другая проблема, не относящаяся к nuget. Отсутствие пакета в репозитории — это лишь следствие иной проблемы.
Повторюсь: не всё можно обернуть в NuGet-пакеты. И тут получаем, что какие-то бинарники у нас таки в репозитории, а какие-то -- вовне.
Н>>Не работает Restore для Content File'ов ( https://nuget.codeplex.com/workitem/2094 ) W>Status: Closed
По ссылкам не ходи, сразу пиши.
This scenario doesn't meet the bar for consideration as a feature.
HgLab: Mercurial Server and Repository Management for Windows
Re: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
не знаю, что такое нугет, все зависимости храню в отдельных репозиториях (своих собственных). Т.е. есть репозиторий для моего проекта и по одному репозиторию на каждую зависимость (зависимости у меня в основном в исходниках, бинарных мало). В зависимостях иногда приходится что-то править, и хранить изменения сразу в репозитории мне проще, чем возиться с патчами. Бинарные же зависимости храню так, что бы не изобретать для них отдельный механизм.
Репозитории отдельные, ибо проектов много, и зависимости у них пересекаются.
В репозитории проекта есть файлик, в котором перечислены ссылки на зависимости и их версии — что-то вроде сабрепов меркуриала. Ну и есть тулза, которая вытаскивает все нужное для проекта.
Здравствуйте, enji, Вы писали:
E>не знаю, что такое нугет, все зависимости храню в отдельных репозиториях (своих собственных). Т.е. есть репозиторий для моего проекта и по одному репозиторию на каждую зависимость (зависимости у меня в основном в исходниках, бинарных мало). В зависимостях иногда приходится что-то править, и хранить изменения сразу в репозитории мне проще, чем возиться с патчами. Бинарные же зависимости храню так, что бы не изобретать для них отдельный механизм. E>Репозитории отдельные, ибо проектов много, и зависимости у них пересекаются.
E>В репозитории проекта есть файлик, в котором перечислены ссылки на зависимости и их версии — что-то вроде сабрепов меркуриала. Ну и есть тулза, которая вытаскивает все нужное для проекта.
E>ЗЫ С++, меркуриал
Единственная причина по которой вы делаете именно так, а не иначе — это отсутствие в мире C++ менеджера пакетов от слова "совсем". У топикстартера менеджер пакетов есть, но он не хочет.
Re[3]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Я уже приводил в качестве примера libgit2 и libgit2sharp, который нельзя было завернуть в NuGet-пакет потому, что он искал нативные DLL'ки не в тех местах, в которые NuGet их мог положить. Посему, не всё можно засунуть в NuGet.
Эта проблема не имеет никакого отношения к NuGet. С нативными библиотеками всегда много геморроя — чаще всего проблемы связаны как раз с поиском нативных зависимостей (субъективная статистика). Лечится либо дополнительным билд степом, который копирует что надо куда надо, либо настройкой уместных переменных окружения в момент запуска (обычно достаточно добавить нужные пути в Path).
Здравствуйте, andyag, Вы писали:
A>Единственная причина по которой вы делаете именно так, а не иначе — это отсутствие в мире C++ менеджера пакетов от слова "совсем". У топикстартера менеджер пакетов есть, но он не хочет.
Такой механизм удобен тем, что нет разницы — своя библиотека или чужая, обе используются одинаково. Опять же, менеджер пакетов не поможет мне хранить изменения в сторонних либах...
Re[4]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, enji, Вы писали:
E>Здравствуйте, andyag, Вы писали:
A>>Единственная причина по которой вы делаете именно так, а не иначе — это отсутствие в мире C++ менеджера пакетов от слова "совсем". У топикстартера менеджер пакетов есть, но он не хочет.
E>Такой механизм удобен тем, что нет разницы — своя библиотека или чужая, обе используются одинаково.
В случае с менеджером пакетов разницы тоже не было бы. Чужие библиотеки брались бы из какого-то паблик репозитория, свои — из внутреннего корпоративного. Во всяких .NET и Java по умолчанию поступают именно так.
E>Опять же, менеджер пакетов не поможет мне хранить изменения в сторонних либах...
Вносить локальные изменения в сторонние библиотеки — это плохая практика, т.к. "чужие" библиотеки после этого сразу же становятся "своим" кодом со всеми вытекающими последствиями. Я не спорю, что иногда могут быть серьёзные причины внести правки, но менеджер пакетов этому никак не помешает: делается форк библиотеки, вносятся правки, библиотека выкладывается куда-то во внутренний репозиторий, делается пул-риквест автору. В итоге, пока правки не попадут в основной код, можно сидеть на своей версии, а когда автор примет пул-риквест, снова можно переключиться на основную версию в паблик репозитории.
Re[2]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Wolverrum, Вы писали:
W>А вот в TeamCity интеграция с nuget изкаробки Что, конечно же не отменяет плясок с ТФС Тем не менее, тоже не аргумент ввиду того, что с минимальными (нет, серьезно!) усилиями выкачку бинарных зависимостей можно встроить в билдскрипт или проект. W>Из практики: Package Restore бесполезен.
Ну в приведенном примере с TFS пляски были из-за достаточно специфичного сценария (используемые пакеты добавляли свои *.target-файлы в проект, поэтому его нельзя было запускать на сборку — динамическое изменение сценария MSBuild во время исполнения не поддерживается).
А вообще у меня вопрос: почему "Package Restore бесполезен" и как вы реализуете сборку проектов (с зависимостями в NuGet) на билд-серверах?
Re: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Нахлобуч, Вы писали:
Н>Честно сказать, не самые убедительные доводы. У кого какое мнение на этот счет?
Я лично за NuGet.
Проблема отсутствия интернета решается с помощью локального прокси NuGet.
Могу порекомендовать ProGet: http://inedo.com/proget/overview
Он умеет и NuGet пакеты выдавать и быть сервером символов и сервером исходников.
А с появлением NuGet для C++ через CoApp можно относительно легко создавать свои пакеты C++ и отлаживать их.
При этом не нужно компилировать и вытаскивать каждый раз исходники, что существенно экономит время.
Здравствуйте, Нахлобуч, Вы писали:
Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
Наиболее правильный вариант — это хранить все исходники всех зависимостей у себя в системе контроля версий. Скажу даже более, их нужно подписывать только своим ключом. При этом избегать хранения DLL/LIB/EXE файлов, т.к. это может раздуть репозиторий и привнести неоднозначности при сборке.
Возможно для многих людей это не очевидно, но если не делать так, как я только что посоветовал, происходят такие веши:
Блин, как же мне вернуться на тот revision чтобы проверить вот этот очень специфический случай зависящий от стороней библиотеки версии X.X от 24 июня 2013 года?
Приложение падало с NullReferenceException у одного клиента (у остальных 999-ти работало). Оказалось, что на машине клиента кто-то поставил в GAC модифицированную версию open source библиотеки с таким же strong name, поэтому наша программа невольно использовала эту несанкционированную и непроверенную версию модуля. А всё потому, что большинство open source проектов светят везде свои .snk ключи, вообще не задумаваясь к чему это может привести. Коммерческие поставщики (например, VistaDB) также этим грешат. Поэтому, переподписывайте все сторонние модули которые вы используете, иначе будет вам GAC-hell. Естественно, NuGet не уместен при таких требованиях
Блин, сайт open source библиотеки умер, автор удалил NuGet пакет из репозитория. Что же нам теперь делать? Где взять сорцы?
Опять же, восприятие решения вашего вопроса сильно зависит от отношения к работе и проекту того или иного человека. Если это попрыгун который меняет работу раз в год или два то ему пофиг на все и он будет кричать "за NuGet". Почему? Потому что его не коснется то, что будет с проектом через 3 года и ему все равно, он просто плывет по течению как бревно на сплаве.
В то же время, NuGet просто необходимо использовать для таких инфраструктурных вещей как ASP.NET, MVC, Azure. Если вы делаете вэб-приложение, то NuGet можно использовать более широко и вольно, т.к. нет проблемы GAC-hell, плюс время активной разработки вэб-проектов зачастую ниже. Также ниже плотность логики и нет такой необходимости возвращаться к деталям из ревизии XXXX. Т.е. NuGet для вэба работает намного лучше.
В итоге получаем такую схему:
Для десктоп приложений — NuGet вообще не рекомендуется использовать, так как можно нарваться на GAC-hell
Для остальных приложений — NuGet можно использовать (и иногда даже нужно). Но с опаской и аккуратно. Оценивайте время жизни проекта. Если это enterprise или B2B с временем жизни > 3 лет, то минимизируйте использование NuGet, так как даже самое, на первый взгляд, невинное изменение в сторонней библиотеке будет ломать вашу функциональность и процессы. Плюс со временем библиотеки будут скисать, а вам придется их исправлять понемногу, без исходного кода тут никак.
Инсталлируемые вэб-приложения — см. десктоп приложения, т.к. тоже могут быть отравлены из GAC'а
Здравствуйте, Aquilaware, Вы писали:
A>Блин, как же мне вернуться на тот revision чтобы проверить вот этот очень специфический случай зависящий от стороней библиотеки версии X.X от 24 июня 2013 года?
У тебе версионируется файл packages.config с указанием версий пакетов. Ты просто откатываешься до 24 июня 2013 года, в той ревизии файла packages.config будет указана версия X.X, она и подтянется.
A>Приложение падало с NullReferenceException у одного клиента (у остальных 999-ти работало). Оказалось, что на машине клиента кто-то поставил в GAC модифицированную версию open source библиотеки с таким же strong name, поэтому наша программа невольно использовала эту несанкционированную и непроверенную версию модуля. А всё потому, что большинство open source проектов светят везде свои .snk ключи, вообще не задумаваясь к чему это может привести. Коммерческие поставщики (например, VistaDB) также этим грешат. Поэтому, переподписывайте все сторонние модули которые вы используете, иначе будет вам GAC-hell. Естественно, NuGet не уместен при таких требованиях
Почему неуместен? В тех исключительно редких случаях, когда кто-то сталкивается с проблемой злоупотребления чужими (хоть и опубликованными) strong name ключами, он может переподписать сборки своим ключом и хранить их в своей NuGet-инфраструктуре. Исходники сторонних библиотек дублировать в свой репозиторий не нужно.
A>Блин, сайт open source библиотеки умер, автор удалил NuGet пакет из репозитория. Что же нам теперь делать? Где взять сорцы?
А если библиотка вообще не open source и в стандартном источнике NuGet никогда не была опубликована?
A>Опять же, восприятие решения вашего вопроса сильно зависит от отношения к работе и проекту того или иного человека. Если это попрыгун который меняет работу раз в год или два то ему пофиг на все и он будет кричать "за NuGet". Почему? Потому что его не коснется то, что будет с проектом через 3 года и ему все равно, он просто плывет по течению как бревно на сплаве.
По-моему, это человек, который дампит исходники third party библиотек в общий репозиторий как раз и саботирует долгосрочную поддержку. Через какое-то время никто уже не помнит, кто и когда обновлял эти библиотеки (путём тупого накатывания снэпшота исходников сторонней библиотеки поверх), какие патчи (подводные мины) внедрял, etc.
Здравствуйте, Qbit86, Вы писали:
Q>У тебе версионируется файл packages.config с указанием версий пакетов. Ты просто откатываешься до 24 июня 2013 года, в той ревизии файла packages.config будет указана версия X.X, она и подтянется.
Вы слишком верите в интернет. Когда я захочу вернутся NuGet уже коростой пойдет с кодом 404.
Q>он может переподписать сборки своим ключом и хранить их в своей NuGet-инфраструктуре. Исходники сторонних библиотек дублировать в свой репозиторий не нужно.
Он может переподписать. Но не будет. Потому что лень побеждает. Напрягаться это ведь не модно, правда ведь? А зарплату и так платят. "Все работает на моей машине это у вас винды кривые"
Q>А если библиотка вообще не open source и в стандартном источнике NuGet никогда не была опубликована?
Без комментариев, так как это не относится к NuGet.
Q>По-моему, это человек, который дампит исходники third party библиотек в общий репозиторий как раз и саботирует долгосрочную поддержку.
Надеюсь вы еще поработаете под санкциями. И тогда, возможно, придет понимание того, кто же был прав, а кто саботировал с виду стройный процесс.
Должен признать, что за время своей профессиональной деятельности (15+ лет) я пережил несколько градаций взглядов. Начиная от наивной как у вас, заканчивая образом парня в треуголке из фольги, который доверяет только здравому смыслу, своему репозиторию, ключу и никому больше и везде видит заговор.
Здравствуйте, Слава, Вы писали:
С>К вашему сведению: люди меняют работу не потому, что им хочется "прыгать", а потому что это лучший способ увеличить зарплату. Вдруг вы не в курсе.
Ты говоришь «хочется прыгать» так, будто это что-то плохое!
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: NuGet Package Restore или хранение исходников в VCS
Здравствуйте, Aquilaware, Вы писали:
A> Блин, сайт open source библиотеки умер, автор удалил NuGet пакет из репозитория. Что же нам теперь делать? Где взять сорцы?
Это невозможно. Функция удаления пакета из репозитория nuget.org отсутствует.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
