Здравствуйте, спасибо за статью!
Не рассматривали OpenID Connect в качестве альтернативы? Это как раз слой аутентификации поверх OAuth. Вроде были пакеты для его поддержки в ASP.Net.
Мне кажется, что "поставить библиотеку" — вещь все-таки нужная, когда речь идёт о зависимостях. Правильную библиотеку, при обнаружении в ней неприятного косяка (допустим, в какой-нибудь libpng, которую использует треть софта в системе), легко обновить, если системный ПМ сам разруливает зависимости. Иначе, когда весь софт идёт монолитным пакетом, то и обновлять надо каждую программу отдельно. За примером далеко ходить не надо — Windows Installer в зависимости не умеет (а хочется), и в итоге разработчики декстопного софта кладут dll-ки всяких C++ runtime прямо в каталог приложения, чтобы было проще деплоить. При этом, сам MS рекомендует ставить рантаймы официальным инсталлятором, чтобы они были отдельными пакетами в системе и их можно было обновить отдельно.
Я в целом согласен, что системный ПМ — это что-то про готовые, "релизные" версии ПО. Конечному пользователю не нужно (и даже вредно в случае серверного ПО) ставить что-то, относящееся к разработке — include-ы/lib-ы, дебажные версии и т.д. Но сразу же возникает ряд вопросов и тонких моментов:
Кто (системный/языковой ПМ) должен ставить include/lib? А отладочные символа? А дебажные версии dll/so?
Допустим, что системный ПМ ставит только релизные бинарники, и больше ничего. Значит, бинарниками и прочими вещами для разработки должен заведовать языковой ПМ. А он справится с этим? Системный тем и хорош, что учитывает особенности конкретного семейства ОС или даже дистрибутива. Значит, придется наш C++ Package Manager учить разбираться и в PE/ELF, и в различных архтектурах?
Допустим, что ЛЮБЫЕ нативные бинарники мы ставим системным ПМ, а языковой ПМ занимается только специфичными для языка аспектами — например, инклудами в случае C++, или биндингами к более высокоуровневым языкам, или самим исходным кодом библиотеки. Казалось бы, неплохой вариант. Например, header-only библиотеки жили бы только в языковом ПМ, а библиотеки с компилируемым кодом подтягивались бы еще и системным. Но тогда как это всё увязать? Ссылаться из языкоспецифичного пакета на системный? А получится ли это сделать кроссплатформенно? Что делать с Виндой, где вроде бы как есть системный ПМ, но используется он для установки монолитных "продуктов" а-ля "Фотошоп 2015", а не для приложения с деревом зависимостей?
Как по мне, так единственный заслуживающий внимания «пакетный менеджер» для плюсов — это Find-модули CMake. В принципе, этого могло быть достаточно, если бы на всех популярных платформах был нормальный системный пакетный менеджер. А сейчас лично мне непонятно, какие именно задачи должен решать системный PM, а какие — PM для языка и его экосистемы.
Не рассматривали OpenID Connect в качестве альтернативы? Это как раз слой аутентификации поверх OAuth. Вроде были пакеты для его поддержки в ASP.Net.
Я в целом согласен, что системный ПМ — это что-то про готовые, "релизные" версии ПО. Конечному пользователю не нужно (и даже вредно в случае серверного ПО) ставить что-то, относящееся к разработке — include-ы/lib-ы, дебажные версии и т.д. Но сразу же возникает ряд вопросов и тонких моментов:
Кто (системный/языковой ПМ) должен ставить include/lib? А отладочные символа? А дебажные версии dll/so?
Допустим, что системный ПМ ставит только релизные бинарники, и больше ничего. Значит, бинарниками и прочими вещами для разработки должен заведовать языковой ПМ. А он справится с этим? Системный тем и хорош, что учитывает особенности конкретного семейства ОС или даже дистрибутива. Значит, придется наш C++ Package Manager учить разбираться и в PE/ELF, и в различных архтектурах?
Допустим, что ЛЮБЫЕ нативные бинарники мы ставим системным ПМ, а языковой ПМ занимается только специфичными для языка аспектами — например, инклудами в случае C++, или биндингами к более высокоуровневым языкам, или самим исходным кодом библиотеки. Казалось бы, неплохой вариант. Например, header-only библиотеки жили бы только в языковом ПМ, а библиотеки с компилируемым кодом подтягивались бы еще и системным. Но тогда как это всё увязать? Ссылаться из языкоспецифичного пакета на системный? А получится ли это сделать кроссплатформенно? Что делать с Виндой, где вроде бы как есть системный ПМ, но используется он для установки монолитных "продуктов" а-ля "Фотошоп 2015", а не для приложения с деревом зависимостей?