Здравствуйте, Нахлобуч, Вы писали:

Н>Банальное отсутствие интернета -- и оппа! Это самая тривиальная проблема, но все же стоит упомянуть.
Маломальски коммерческие разработки, как правило, не привязываются к nuget.org. А отсутствие сети в масштабах офиса — это какая-то другая проблема, не nuget. Не аргумент.

Н>Я не могу быть до конца уверенным, что в -- нашем или в "публичном" -- NuGet-сервере всегда будут присутствовать все когда-либо использованные в проекте версии библиотек.
А с VCS, значит, такая уверенность есть? Короче, паранойя — не аргумент.

Н>Нет гарантии, что пакеты не сервере не будут изменены "задним числом".
Иррелевантно. Это никоим оброзом не проблема nuget.

Н>Нужны дополнительные нетривиальные приседания при конфигурировании билд-серверов
Нет, не нужны. И не балд-серверов, а билд-агентов, к слову.

Н>Опять же, не всё есть в NuGet'ах
Это снова какая-то другая проблема, не относящаяся к nuget. Отсутствие пакета в репозитории — это лишь следствие иной проблемы.

Н>Не работает Restore для Content File'ов ( https://nuget.codeplex.com/workitem/2094 )
Status: Closed

Н>

Плюс, для работы Package Restore рекомендуют держать nuget.exe в репозитории с проектом
Рекомендуют != требуют. При минимальной прямоте рук разработчиков в коде проекта нет ничего лишнего и/или глобального.

Здравствуйте, Wolverrum, Вы писали:

Н>>Я всегда могу выполнить hg update до любой версии и все зависимости гарантированно будут на месте
W>Иррелевантно.

Нет. В случае самодостаточного репозитория подобные гарантии у меня есть. В случае, когда требуется еще что-то извне -- всегда есть шанс, что что-то отвалится.

Н>>Не все зависимости и сторонние библиотеки есть в NuGet
W>О_о Что мешает создать свои пакеты для своих проектов в своем (см. выше) репозитории?! Принципиальная опенсорсность проекта разве что?

Я уже приводил в качестве примера libgit2 и libgit2sharp, который нельзя было завернуть в NuGet-пакет потому, что он искал нативные DLL'ки не в тех местах, в которые NuGet их мог положить. Посему, не всё можно засунуть в NuGet.

Здравствуйте, 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.

Здравствуйте, Нахлобуч, Вы писали:

Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.

не знаю, что такое нугет, все зависимости храню в отдельных репозиториях (своих собственных). Т.е. есть репозиторий для моего проекта и по одному репозиторию на каждую зависимость (зависимости у меня в основном в исходниках, бинарных мало). В зависимостях иногда приходится что-то править, и хранить изменения сразу в репозитории мне проще, чем возиться с патчами. Бинарные же зависимости храню так, что бы не изобретать для них отдельный механизм.
Репозитории отдельные, ибо проектов много, и зависимости у них пересекаются.

В репозитории проекта есть файлик, в котором перечислены ссылки на зависимости и их версии — что-то вроде сабрепов меркуриала. Ну и есть тулза, которая вытаскивает все нужное для проекта.

ЗЫ С++, меркуриал

Здравствуйте, enji, Вы писали:

E>не знаю, что такое нугет, все зависимости храню в отдельных репозиториях (своих собственных). Т.е. есть репозиторий для моего проекта и по одному репозиторию на каждую зависимость (зависимости у меня в основном в исходниках, бинарных мало). В зависимостях иногда приходится что-то править, и хранить изменения сразу в репозитории мне проще, чем возиться с патчами. Бинарные же зависимости храню так, что бы не изобретать для них отдельный механизм.
E>Репозитории отдельные, ибо проектов много, и зависимости у них пересекаются.

E>В репозитории проекта есть файлик, в котором перечислены ссылки на зависимости и их версии — что-то вроде сабрепов меркуриала. Ну и есть тулза, которая вытаскивает все нужное для проекта.

E>ЗЫ С++, меркуриал

Единственная причина по которой вы делаете именно так, а не иначе — это отсутствие в мире C++ менеджера пакетов от слова "совсем". У топикстартера менеджер пакетов есть, но он не хочет.

Здравствуйте, Нахлобуч, Вы писали:

Н>Я уже приводил в качестве примера libgit2 и libgit2sharp, который нельзя было завернуть в NuGet-пакет потому, что он искал нативные DLL'ки не в тех местах, в которые NuGet их мог положить. Посему, не всё можно засунуть в NuGet.

Эта проблема не имеет никакого отношения к NuGet. С нативными библиотеками всегда много геморроя — чаще всего проблемы связаны как раз с поиском нативных зависимостей (субъективная статистика). Лечится либо дополнительным билд степом, который копирует что надо куда надо, либо настройкой уместных переменных окружения в момент запуска (обычно достаточно добавить нужные пути в Path).

Здравствуйте, andyag, Вы писали:

A>Единственная причина по которой вы делаете именно так, а не иначе — это отсутствие в мире C++ менеджера пакетов от слова "совсем". У топикстартера менеджер пакетов есть, но он не хочет.

Такой механизм удобен тем, что нет разницы — своя библиотека или чужая, обе используются одинаково. Опять же, менеджер пакетов не поможет мне хранить изменения в сторонних либах...

Здравствуйте, enji, Вы писали:

E>Здравствуйте, andyag, Вы писали:

A>>Единственная причина по которой вы делаете именно так, а не иначе — это отсутствие в мире C++ менеджера пакетов от слова "совсем". У топикстартера менеджер пакетов есть, но он не хочет.

E>Такой механизм удобен тем, что нет разницы — своя библиотека или чужая, обе используются одинаково.

В случае с менеджером пакетов разницы тоже не было бы. Чужие библиотеки брались бы из какого-то паблик репозитория, свои — из внутреннего корпоративного. Во всяких .NET и Java по умолчанию поступают именно так.

E>Опять же, менеджер пакетов не поможет мне хранить изменения в сторонних либах...

Вносить локальные изменения в сторонние библиотеки — это плохая практика, т.к. "чужие" библиотеки после этого сразу же становятся "своим" кодом со всеми вытекающими последствиями. Я не спорю, что иногда могут быть серьёзные причины внести правки, но менеджер пакетов этому никак не помешает: делается форк библиотеки, вносятся правки, библиотека выкладывается куда-то во внутренний репозиторий, делается пул-риквест автору. В итоге, пока правки не попадут в основной код, можно сидеть на своей версии, а когда автор примет пул-риквест, снова можно переключиться на основную версию в паблик репозитории.

Здравствуйте, Wolverrum, Вы писали:

W>А вот в TeamCity интеграция с nuget изкаробки Что, конечно же не отменяет плясок с ТФС Тем не менее, тоже не аргумент ввиду того, что с минимальными (нет, серьезно!) усилиями выкачку бинарных зависимостей можно встроить в билдскрипт или проект.
W>Из практики: Package Restore бесполезен.

Ну в приведенном примере с TFS пляски были из-за достаточно специфичного сценария (используемые пакеты добавляли свои *.target-файлы в проект, поэтому его нельзя было запускать на сборку — динамическое изменение сценария MSBuild во время исполнения не поддерживается).

А вообще у меня вопрос: почему "Package Restore бесполезен" и как вы реализуете сборку проектов (с зависимостями в NuGet) на билд-серверах?

Здравствуйте, Нахлобуч, Вы писали:

Н>Честно сказать, не самые убедительные доводы. У кого какое мнение на этот счет?

Я лично за 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+ лет) я пережил несколько градаций взглядов. Начиная от наивной как у вас, заканчивая образом парня в треуголке из фольги, который доверяет только здравому смыслу, своему репозиторию, ключу и никому больше и везде видит заговор.

Здравствуйте, Aquilaware, Вы писали:

A> Если это попрыгун который меняет работу раз в год или два

К вашему сведению: люди меняют работу не потому, что им хочется "прыгать", а потому что это лучший способ увеличить зарплату. Вдруг вы не в курсе.

Здравствуйте, Слава, Вы писали:

С>К вашему сведению: люди меняют работу не потому, что им хочется "прыгать", а потому что это лучший способ увеличить зарплату. Вдруг вы не в курсе.

Ты говоришь «хочется прыгать» так, будто это что-то плохое!

Здравствуйте, Aquilaware, Вы писали:

A>

Блин, сайт open source библиотеки умер, автор удалил NuGet пакет из репозитория. Что же нам теперь делать? Где взять сорцы?

Это невозможно. Функция удаления пакета из репозитория nuget.org отсутствует.