Традиционно установка программ в Windows происходит следующим образом: находим дистрибутив, загружаем его на свой компьютер, запускаем программу установки и следуем инструкциям. В принципе процедура несложная, но несколько трудоемкая, особенно много времени тратится на поиск нужного дистрибутива.
Для того, чтобы упростить процесс установки ПО, в Windows добавлена возможность установки ПО из пакетов (package). Такой подход используется в операционных системах Linux, суть его заключается в том, что программы хранятся в специальных хранилищах (репозиториях) в виде пакетов, для управления которыми используется менеджер пакетов (напр. apt в Debian). Таким образом установка приложения сводится к выполнению всего одной команды.
Теперь давайте рассмотрим схему управления пакетами (Package Management), реализованную в Windows. Она состоит из четырех основных составляющих:
• Package Sources — источник пакетов, он же репозиторий. Место, где хранятся установочные пакеты программ. В качестве расположения источника может быть указан URL-адрес в интернете, общая папка в локальной сети или локальная папка на компьютере;
• PackageManagement Providers — провайдеры (поставщики) пакетов, отвечающие за доступ к источникам пакетов. Каждый поставщик может управлять одним или несколькими источниками;
• PackageManagement Core — ядро управления пакетами. Программный интерфейс, обеспечивающий взаимодействие поставщиков с конечными пользователями;
• End User — конечный пользователь, т.е. тот, кто пользуется функционалом Package Management с помощью командлетов PowerShell.
Как следует из схемы, управление пакетами в Windows осуществляется исключительно с помощью PowerShell. Для этой цели предназначен специальный модуль PackageManagement (ранее известный как OneGet), входящий в состав PowerShell начиная с версии 5.0. Для более ранних версий PowerShell модуль можно установить вместе с WMF 5.1 либо отдельно, из репозитория PowerShell Gallery.
В модуль входит 13 командлетов, подробное описание можно найти здесь.
Внимание!
Перед тем, как приступать к управлению пакетами, обязательно проверьте, разрешено ли у вас выполнение скриптов. Вывести текущую политику выполнения скриптов можно командой:
Get-ExecutionPolicy
По умолчанию выполнение скриптов PowerShell запрещено (Restricted). Для успешной работы с пакетами необходимо установить значение Unrestricted или ByPass, например:
Set-ExecutionPolicy Unrestricted
Для начала проверим, какие из поставщиков установлены в системе. Для этого выполним команду:
Get-PackageProvider
По умолчанию в Windows имеются следующие поставщики пакетов:
• MSI — поставщик для обработки файлов msi (файлы установки Windows);
• MSU — поставщик для обработки файлов msu (файлы обновлений Windows);
• PowerShellGet — служит для управления модулями PowerShell;
• Programs — отвечает за инвентаризационные данные обо всех программных продуктах, зарегистрированных в оснастке ″Удаление или изменение программы″;
Теперь посмотрим доступные источники командой:
Get-PackageSource
На данный момент из источников доступен только репозиторий PSGallery, поставщиком которого является PowerShellGet.
Ну собственно источник у нас имеется, поставщик тоже, можно приступать к установке пакетов. В качестве примера установим модуль PSWindowsUpdate.
Первое, что нам нужно сделать — это найти нужный пакет. Следующая команда выведет все версии нужного пакета, имеющиеся в указанном репозитории:
Find-Package -Provider PowerShellGet -Name PSWindowsUpdate -AllVersions
Примечание. Для работы с репозиториями небходим провайдер NuGet, поэтому при первом обращении вам будет предложено установить его. NuGet — это бесплатный менеджер пакетов с открытым исходным кодом, предназначенный для платформы Microsoft. Он требуется для работы с пакетами NuGet (.nupkg).
Следующей командой установим найденный пакет, дополнительно укажем требуемую версию:
Install-Package -Name PSWindowsUpdate -RequiredVersion 2.1.1.1 -Source PSGallery -Provider PowerShellGet -Force
Примечание. Версию пакета указывать не обязательно, в этом случае будет установлена наиболее свежая.
После установки проверим наличие пакета:
Get-Package -Name PSWindowsUpdate
и самого модуля:
Get-Module -Name PSWindowsUpdate -ListAvailable
Как видите, все на месте.
Ну и завершим демонстрацию удалением свежеустановленного пакета:
UnInstall-Package -Name PSWindowsUpdate -Force
Этот пример наглядно показывает принцип работы с пакетами. Если вспомнить схему, то действия по установке пакета выглядят примерно так:
Пользователь выполняет команду PowerShell для установки пакета -> Модуль PackageManagement обращается к ядру управления пакетами (PackageManagement Core) -> Ядро обрабатывает команду PowerShell и передает ее нужному поставщику -> Поставщик обращается к своему источнику, находит в нем требуемый пакет и запускает процесс установки.
И вот тут стоит подробнее объяснить назначение компонента PackageManagement Core. Дело в том, что каждый поставщик имеет свой собственный синтаксис команд, а ядро служит как бы переводчиком, который умеет общаться с каждым поставщиком на его родном языке. При этом конечному пользователю предоставляется строго унифицированный набор команд, независимо от используемого поставщика.
Перейдем к более жизненным примерам и установим какую нибудь программу. Для этого нам понадобится новый источник, поскольку в PSGallery нет ничего, кроме PowerShell модулей. Одним из наиболее популярных публичных источников является репозиторий Chocolatey, им и воспользуемся.
Для доступа к источнику необходим соответствующий поставщик, поэтому выведем список всех доступных для установки поставщиков командой:
Find-PackageProvider
Для работы с Chocolatey рекомендуется использовать одноименный поставщик сhocolatey. Установим его командой:
Install-PackageProvider -Name chocolatey
Еще раз проверим список источников и убедимся, что в нем появился Chocolatey. И чтобы не требовалось подтверждение на установку пакетов, сделаем его доверенным источником:
Set-PackageSource -Name Chocolatey -Trusted
Ради интереса посмотрим, сколько всего пакетов есть в новом репозитории. Сделать это можно командой:
Find-Package -Source Chocolatey | measure | select count
На момент написания статьи количество пакетов в ″шоколадке″ составляет 6533 штуки, и оно постоянно увеличивается.
В качестве примера найдем и установим мой любимый редактор Notepad++:
Find-Package -Name notepadplusplus -Source Chocolatey | Install-Package
Для проверки зайдем в меню Пуск и удостоверимся, чтоNotepad++ действительно установлен и готов к работе.
На этом можно было бы и закончить статью, в заключение написав о том, как легко и просто ставить ПО из пакетов. Но на самом деле все не так красиво, как кажется 🙂 Поэтому не будем останавливаться на достигнутом и попробуем установить еще одно приложение, к примеру архиватор 7zip.
На этот раз для поиска пакета воспользуемся выводом командлета Out-GridView:
Find-Package -Provider chocolatey | sort -Property Name | Out-GridView
А теперь начинается самое интересное — установка пакета проходит без ошибок, но самого приложения нигде нет. Для понимания происходящего запускаем установку пакета с ключом Verbose и видим, что установщик ругается на неизвестную команду Get-OSArchitectureWidth.
При этом сам пакет считается успешно установленным и его можно найти в списке доступных.
Поставщик chocolatey создает в корне диска папку Chocolatey, где хранит все загруженные пакеты. Найдем среди них пакет 7zip и посмотрим его содержимое. Как видите, пакет представляет из себя набор из стандартных инсталляторов и пары powershell скриптов — один для установки, второй для удаления.
При установке приложения из репозитория провайдер сначала загружает файлы пакета, а затем запускает скрипт установки. Откроем установочный скрипт и посмотрим его содержимое. Как видите, он просто выбирает нужный дистрибутив (x32 или x64) и устанавливает его в тихом режиме, а неизвестная команда как раз и служит для определения разрядности системы.
В процессе поисков удалось выяснить, что команда Get-OSArchitectureWidth входит в состав официального поставщика Chocolatey, точнее в один из его модулей. По какой то причине при установке поставщика chocolatey ставится только часть функционала, соответственно установка приложений с его помощью превращается в лотерею. Часть приложений ставится нормально, часть не ставится вообще.
Как можно исправить эту ситуацию? Первое, что приходит на ум, это использовать другого поставщика. Выводим всех подходящих командой:
Find-PackageProvider -Name choco*
Всего для работы с ″шоколадкой″ есть три поставщика. Путем проб и ошибок выбираем ChocolateyGet:
Install-PackageProvider -Name ChocolateyGet
Еще раз попробуем установить 7zip, уже с помощью нового поставщика:
Install-Package -Name 7zip -Source Chocolatey -Provider ChocolateyGet -Force -Verbose
На сей раз все прошло успешно и приложение установлено.
Новый поставщик ChocolateyGet устанавливает приложение choco.exe вместе со всеми дополнениями, включая и недостающие PowerShell модули. Установка производится в директорию C:\ProgramData\chocolatey, туда же загружаются новые пакеты. Что интересно, в процессе установки ChocolateyGet удаляет папку, созданную chocolatey.
В принципе пользоваться провайдером ChocolateyGet вполне можно, с установкой пакетов он справляется неплохо. Но для работы с репозиторием chocolatey гораздо удобнее и проще использовать родной менеджер пакетов choco.exe, о котором и пойдет речь в следующей части статьи.
Годная статья. Немного дополню, устанавливать пакеты Шоко лучше не командлетов install-packege, а спомощью команды нааример choco install 7zip в этом случаее внутренние модули будут подгруженны автоматически, такие как определение разрядности винды. Также если делать установку через choco install будет создан автодеинсталятор ( некоторые пакеты могут быть без скриата деинсталяции). И ещё одна полезеость, можно юзать choco gui и ставить пакеты нажатием на иконки и с удобным поиском.