У меня вопрос, в каком виде будет поставляться переписанный на Найтре Немерле? Да и сама Найтра?

Сейчас Немерле поставляется в виде msi, что не очень удобно для видны и совсем неудобно для *nix.
При этом в дотнете есть устойчивый тренд всё переводить на nuget.
kekekes вроде в одной из веток предлагал перевести Nemerle на nuget, мне это тоже кажется разумной идеей.
Хотя компилятор в nuget — это необычно, но вроде особых ограничений в этом нет.
И с билд серверами проблем меньше будет.
Встанет только вопрос как разбивать поставку на пакеты. Засунуть всё в один?

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

В>При этом в дотнете есть устойчивый тренд всё переводить на nuget.

С нюгетом все хорошо, кроме проблемы "брильянтовой" зависимости по отношению к Nemerle.dll.
Сейчас msi-ник регистрирует Nemerle.dll в GAC и прописывает туда специальную прокси-сборку которая позволяет использовтаь Nemerle.dll установленной версии для любой другой сборки которая была скомпилирована с предыдущими ее версиями.

Как добиться этого с nuget-ом не ясно. Точнее неясно возможно ли этого добиться.

Пихнуть немерл в nuget не проблема. Плагин Найтры к РеШарперу (и все плагины созданные с помощью найтры) будет ставиться через решарперный клон nuget-а. А вот что делать с Nitra.Runtime.dll и с Nemerle.dll не ясно.

В>Хотя компилятор в nuget — это необычно, но вроде особых ограничений в этом нет.

Для сборки из студии это сделать возможно. Для сборки из командной строки будет не очень удобно, что компилятор валяется черти где.

В>И с билд серверами проблем меньше будет.
В>Встанет только вопрос как разбивать поставку на пакеты. Засунуть всё в один?

С разбивкой особых проблем нет. Но есть проблема совместимости сборок разных версий. В один процесс (в том числе и в VS) нельзя загружать длл-и разных версий. Иначе начинается ад. Ну, и бриллиантовая проблема никуда не девается.

Бриллиантовая зависимость — не уникальная для Nemerle проблема. Вот вроде FSharp.Core в nuget положили https://github.com/fsharp/fsharp/blob/master/FSharp.Core.Nuget/FSharp.Core.3.1.nuspec
Из того, с чем я сталкивался — очень многие либы для веба зависят от Newtonsoft.Json. И ничего, живут люди.

Вообще проблема с зависимостью от Nemerle.dll возникнет как только будут два разных nuget пакета с разными версиями.
Не заставлять же всех программистов, пишущих на шарпе ставить Nemerle как только им понадобилася либа на нём написанная.

Проблема конечного приложения, в котором разные сборки зависят от разных версий на сколько я понимаю решается через прописывание binding redirect.
Не очень удобно, но в большинстве случаев это удобнее, чем ставить msi.

Проблема с решарпером и Nitra.Runtime.dll (я надеюсь он нужен будет только языковым средствам, а не конечным приложениям) сложнее.
Но это опять стандартная проблема приложений подгружающих сторонние плагины. В том же решарпере запросто могут быть плагины, тянущие разные версии Newtonsoft.Json.
И я уверен, что как-то эту проблему решали. Может там под каждый плагин свой AppDomain создают.

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

В>Бриллиантовая зависимость — не уникальная для Nemerle проблема. Вот вроде FSharp.Core в nuget положили https://github.com/fsharp/fsharp/blob/master/FSharp.Core.Nuget/FSharp.Core.3.1.nuspec

Надо посмотреть на FSharp. Может они там что-то новое придумали. Ранее они использовали подхода который мы у них и утырили — помещение сборки в ГАК + помещение туда же специальной сборки которая заставляет рантайм выбирать именно ее вместо более ранних версий.

Возможно они это сделали для 4.5.1 фреймворка, так как там (по слухам) изменилась политика версионирования. Но это надо все проверять (разбираться).

В>Из того, с чем я сталкивался — очень многие либы для веба зависят от Newtonsoft.Json. И ничего, живут люди.

Это уже немного не то. Они не выставляют наружу базовых типов, как это делают Nemerle.dll и FSharp.Core.dll.

В>Вообще проблема с зависимостью от Nemerle.dll возникнет как только будут два разных nuget пакета с разными версиями.

Ну, ежу понятно, что при перезде на нагет нужно выгладывать Nemerle.dll в отдельную сборку и делать так, чтобы все другие пакеты брали всегда самую старшую версию. Но черт кроется в деталях.

В>Не заставлять же всех программистов, пишущих на шарпе ставить Nemerle как только им понадобилася либа на нём написанная.

К сожалению, не только всех программистов, но и пользователей. В принципе проблема решается правкой дотнетных конфигов, но на это надо иметь не хилый сикл. Не очень продвинутым проще поставить немерл из msi.

В>Проблема конечного приложения, в котором разные сборки зависят от разных версий на сколько я понимаю решается через прописывание binding redirect.
В>Не очень удобно, но в большинстве случаев это удобнее, чем ставить msi.

Это в сто раз проще чем правка конфигов. Особенно кода речь идет о студии. Там вообще все очень не просто.

В>Проблема с решарпером и Nitra.Runtime.dll (я надеюсь он нужен будет только языковым средствам, а не конечным приложениям) сложнее.

Nitra.Runtime.dll имеет те же проблемы. Разве что нужна она в меньшем количестве приложений.

В>Но это опять стандартная проблема приложений подгружающих сторонние плагины. В том же решарпере запросто могут быть плагины, тянущие разные версии Newtonsoft.Json.
В>И я уверен, что как-то эту проблему решали. Может там под каждый плагин свой AppDomain создают.

Надо смотреть что придумали в F#-е. У них самый похожий (если не сказать "аналогичный") юзкейс.