Здравствуйте, Нахлобуч, Вы писали:
Н>Банальное отсутствие интернета -- и оппа! Это самая тривиальная проблема, но все же стоит упомянуть.
Маломальски коммерческие разработки, как правило, не привязываются к 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 отсутствует.
Если нам не помогут, то мы тоже никого не пощадим.