Заметки о Windows и других программных продуктах Microsoft...

Управление пакетами в Windows (часть 1)

Управление пакетами в Windows (часть 1)

Традиционно установка программ в 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

установка пакета из chocolatey

 

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

проверка установки

 

На этом можно было бы и закончить статью, в заключение написав о том, как легко и просто ставить ПО из пакетов. Но на самом деле все не так красиво, как кажется 🙂 Поэтому не будем останавливаться на достигнутом и попробуем установить еще одно приложение, к примеру архиватор 7zip.

На этот раз для поиска пакета воспользуемся выводом командлета Out-GridView:

Find-Package -Provider chocolatey | sort -Property Name | Out-GridView

поиск пакета с помощью Out-GridView

 

А теперь начинается самое интересное — установка пакета проходит без ошибок, но самого приложения нигде нет. Для понимания происходящего запускаем установку пакета с ключом Verbose и видим, что установщик ругается на неизвестную команду Get-OSArchitectureWidth.

ошибка при установке пакета из chocolatey

 

При этом сам пакет считается успешно установленным и его можно найти в списке доступных.

поиск установленного пакета

 

Поставщик chocolatey создает в корне диска папку Chocolatey, где хранит все загруженные пакеты. Найдем среди них пакет 7zip и посмотрим его содержимое. Как видите, пакет представляет из себя набор из стандартных инсталляторов и пары powershell скриптов — один для установки, второй для удаления.

состав пакета

 

При установке приложения из репозитория провайдер сначала загружает файлы пакета, а затем запускает скрипт установки. Откроем установочный скрипт и посмотрим его содержимое. Как видите, он просто выбирает нужный дистрибутив (x32 или x64) и устанавливает его в тихом режиме, а неизвестная команда  как раз и служит для определения разрядности системы.

установочный скрипт

 

В процессе поисков удалось выяснить, что команда Get-OSArchitectureWidth входит в состав официального поставщика Chocolatey, точнее в один из его модулей. По какой то причине при установке поставщика chocolatey ставится только часть функционала, соответственно установка приложений с его помощью превращается в лотерею. Часть приложений ставится нормально, часть не ставится вообще.

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

Find-PackageProvider -Name choco*

Всего для работы с ″шоколадкой″ есть три поставщика. Путем проб и ошибок выбираем ChocolateyGet:

Install-PackageProvider -Name ChocolateyGet

установка альтернативного поставщика chocolatey

 

Еще раз попробуем установить 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 и ставить пакеты нажатием на иконки и с удобным поиском.

Статья интересная. Возник вопрос — можно ли как-то сделать локальный репозиторий пакетов как в Linux, дабы не тянуть кучу одного и того же из интернета при массовых установках?

Если честно, так и не понял в чём преимущество данного метода, перед традиционным.

Это смотря где использовать. Если одну прогу поставить, то никакого особо преимущества нет.

а если несколько? что тут 10 раз нажать на кнопку что там. ну или тут батник запустить и там батник запустить.

Основной плюс в наличии репозитория. Ничего не надо скачивать и хранить, все уже готово. И софт весь свежий и проверенный.

Да, можно батник, можно кучу прогоамм поставить одной командой, можно на удаленный ( ые) пк поставить кучу программ парой команд. Можно запилитб свой репозиторий и свои пакеты. И пакеты это всеголишь транспорт команд. Это не обязательно установку програм, это вообще любой скрипт. Хочешь файлы докинул, хочешь реестр попраыил, хочешь настройки винды или окружения сделал. Вообщем при прямых руках все что угодно, а если скрестить это с wds, то можно сотни пк устанавливать и настраивать вообще без проблем