Comments 23
Намного хуже в винде отсутствие не пакетного менеджера, а приницпа «наследил — убери». До сих пор не понимаю как можно было додуматься сохранять настройки в реестр, вместо того, чтобы писать в конфигурационные файлы в папках системы\приложения\драйверов. И в целом бОльшая часть приложений написано таким образом, что не удаляют за собой полностью, в том числе и от мелкософта(ваша любимая VS например очень мусорит). Заодно это источник многих ошибок, которые очень тяжко потом ловить и фиксить. Это кстати одна из причин почему винду проще переставить, чем очистить.
Не уверен, что реестр — плохо. Представьте, что вы на Debian. У вас установлен пакет, у которого в конфиге что-то изменено. И вот вышел апдейт, вы хотите обновить. И apt предоставит вам экран, где спросит оставить ли версию мейнтейнеров, оставить ли адаптированную или сравнить версии.
А теперь представьте, что вы обновляете 100500 машин и участие в подобных диалогах вам недоступно.
А вот если вы что-то меняете в реестре, то изменение всегда атомарное. И дельта «конфигов» между версиями ляжет нормально.
Но вот то, что реестр сложнее чистится — это согласен конечно.
А теперь представьте, что вы обновляете 100500 машин и участие в подобных диалогах вам недоступно.
А вот если вы что-то меняете в реестре, то изменение всегда атомарное. И дельта «конфигов» между версиями ляжет нормально.
Но вот то, что реестр сложнее чистится — это согласен конечно.
В реестре пишется в отдельную папку приложения, в чем проблема? Кстати сейчас реестр использовать не рекомендуют.
А OpenGet над ними начальник.
Это что за зверь?
А я-то думал: куда делся удобный command-line'овый nuget.exe. Жаль, что унификация через powershell слелана так, что без мануала нужную команду не угадаешь.
Спасибо за статью, отличный формат для вводного курса «как это в целом вообще устроено». То самое, чего больше всего не хватает в мануалах, особенно MSDN.
Спасибо за статью, отличный формат для вводного курса «как это в целом вообще устроено». То самое, чего больше всего не хватает в мануалах, особенно MSDN.
Спасибо!
По поводу пропавшего nuget.exe — не спешите расстраиваться, он еще жив.
Ведь без него не собрать пакет и не отправить в репозиторий. Поэтому вы можете его поставить:
Там вообще много чего еще есть:
По поводу пропавшего nuget.exe — не спешите расстраиваться, он еще жив.
Ведь без него не собрать пакет и не отправить в репозиторий. Поэтому вы можете его поставить:
Install-Package NuGet.CommandLine
Там вообще много чего еще есть:
WARNING: 'nuget' matched package 'NuGet.CommandLine/4.1.0' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'nuget' matched package 'NugetPackageExplorer/3.23' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'nuget' matched package 'NugetPackageManager/2.8.60318.667' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'nuget' matched package 'NuGet.vs/2.8.60318.667' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'nuget' matched package 'NugetPackageManagerForVisualStudio2013/2.8.50313.4600' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'nuget' matched package 'NuGet.ContextMenu/1.0.0.20141024' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'nuget' matched package 'SymbolSource.Integration.NuGet.CommandLine/1.3.4' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'nuget' matched package 'nugetupload/1.0.2' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'nuget' matched package 'nuget-credentialprovider-vss/0.23.0' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'nuget' matched package 'visualstudio2015-nugetpackagemanager/3.5.0' from provider: 'Chocolatey', source 'chocolatey'.
WARNING: 'NuGet' matched package 'NuGet/1.3.3' from provider: 'PowerShellGet', source 'PSGallery'.
По-моему в nuget только библиотеки для .NET, разве нет?
Не, там полно всего: nuget.org
Есть куча утилит всяких, например. Но всех их объединяет одно — чистый формат NuGet. Чего не скажешь про пакеты репозиториев провайдера Chocolatey, где можно встретить как чистый NuGET, так и MSI, завернутый в NuGet и даже ZIP, завернутый в NuGet.
Есть куча утилит всяких, например. Но всех их объединяет одно — чистый формат NuGet. Чего не скажешь про пакеты репозиториев провайдера Chocolatey, где можно встретить как чистый NuGET, так и MSI, завернутый в NuGet и даже ZIP, завернутый в NuGet.
Подавляющее большинство — да. Но если пролистать дальше, то можно найти и что-то другое.
Например:
пакет конфигов: NLog.Config
пакет приложения: Selenium.Chrome.WebDriver
пакет библиотека, но не .Net: knockoutjs
пакет для .Net, но не библиотека, а тулза: FAKE
Например:
пакет конфигов: NLog.Config
пакет приложения: Selenium.Chrome.WebDriver
пакет библиотека, но не .Net: knockoutjs
пакет для .Net, но не библиотека, а тулза: FAKE
И как же тогда добавить провайдеры npm и pip в OneGet? А что если будет конфликт имён? А как мне пользоваться всякими npm install без флага -g через OneGet?
Не стоит этим пользоваться в таких целях. Вопреки написанному, это не замена pip и yarn/npm/gem. Это ближе к apt/yum/whatever/chocolate.
А в чем особо разница между первой группой и второй? И почему вы считаете, что не стоит пользоваться?
apt/yum/chocolate — для приложений, которые устанавливаются в систему. pip/npm — для пакетов, специфичных для языков/проектов. Я вообще pip вне virtual environment стараюсь не пользоваться. Да и npm в пределах проекта в основном. Я не знаю как буду реализованы провайдеры в OneGet, но точно знаю, что у меня не будет OneGet в системе отличной от Windows. А вот аналог apt в Windows это да, хорошо.
Неубедительно.
Все устанавливается в систему.
Только apt раскидывает по FHS (опять же не всегда), а pip ставит в dist-packages. В начале статьи я привел случаи, когда их вообще не отличишь.
Пока абстрактно — правильно звучит. Начнете копать, сделаете более точные утверждения и ситуация развернется.
Все они просто раскладывают код, который либо сам запускается и выполняет функционал, либо является библиотекой для кого-то. И все они могут быть где угодно на файловой системе. Деление на языки и место установки очень условно и является вопросом традиций и привычек.
Устанавливаются в систему
Все устанавливается в систему.
Только apt раскидывает по FHS (опять же не всегда), а pip ставит в dist-packages. В начале статьи я привел случаи, когда их вообще не отличишь.
pip/npm — для пакетов, специфичных для языков/проектов
Пока абстрактно — правильно звучит. Начнете копать, сделаете более точные утверждения и ситуация развернется.
Все они просто раскладывают код, который либо сам запускается и выполняет функционал, либо является библиотекой для кого-то. И все они могут быть где угодно на файловой системе. Деление на языки и место установки очень условно и является вопросом традиций и привычек.
Первоначальное предназначение нугета — быть пакетным менеджером для .net языков. Т.е. это аналог npm в мире .net. Всякие вангеты и шоколати его абьюзят как хотят. Родной нугет клиент ничего в «систему» не ставит.
И как же тогда добавить провайдеры npm и pip в OneGet?
Я так понимаю, его еще не сделали. В процессе.
Вот wish-list провайдеров от народа.
А что если будет конфликт имён?
Запросит указать точного провайдера. Есть такая опция у Install-Package.
Sign up to leave a comment.
Терминология OneGet, NuGet, Chocolatey, PowerShellGet — разложим по полочкам