Что такое package manager

Диспетчер пакетов Windows

Диспетчер пакетов Windows — это комплексное решение для управления пакетами, которое состоит из программы командной строки и набора служб для установки приложений в Windows 10 и Windows 11.

Диспетчер пакетов Windows для разработчиков

Разработчики используют программу командной строки winget для обнаружения, установки, обновления, удаления и настройки проверенного набора приложений. После установки разработчики могут получить доступ к winget с помощью терминала Windows, PowerShell или командной строки.

Диспетчер пакетов Windows для независимых поставщиков программного обеспечения

Независимые поставщики программного обеспечения могут использовать Диспетчер пакетов Windows в качестве канала распространения пакетов программного обеспечения, содержащих их средства и приложения. Для отправки пакетов программного обеспечения (содержащих установщики MSIX, MSI или EXE) в Диспетчер пакетов Windows мы предоставляем на сайте GitHub репозиторий манифестов пакетов сообщества Майкрософт с открытым исходным кодом. Независимые поставщики программного обеспечения могут передавать в него манифесты пакетов, которые затем могут быть включены в Диспетчер пакетов Windows. Манифесты проверяются автоматически, однако они также могут просматриваться вручную.

Основные сведения о диспетчерах пакетов

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

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

Диспетчеры пакетов сторонних разработчиков могут использовать репозиторий манифестов пакетов сообщества Майкрософт для пополнения своего каталога программного обеспечения.

Источник

Представляем Windows Package Manager 1.0

Мы начали путь к созданию собственного диспетчера пакетов для Windows 10, когда анонсировали предварительную версию диспетчера пакетов Windows на Microsoft Build 2020. Мы выпустили проект на GitHub как совместный с открытым исходным кодом, и участие сообщества было очень важным аспектом! И вот недавно прошла конференция Microsoft Build 2021.

И мы рады объявить о выпуске Windows Package Manager 1.0! Подробности под катом!

Клиент

Как мне это получить?

Если вы используете любую текущую сборку Windows Insider или подписались на группу Windows Package Manager Insider, возможно, она у вас уже есть. Диспетчер пакетов Windows распространяется вместе с установщиком приложений из Microsoft Store. Вы также можете загрузить и установить диспетчер пакетов Windows со страницы выпусков GitHub или просто установить последнюю доступную версию.

Репозиторий сообщества Microsoft

Windows Package Manager Manifest Creator Preview

Мы также выпускаем еще один инструмент с открытым исходным кодом, который поможет отправлять пакеты в репозиторий сообщества Microsoft. Откройте свой любимый интерфейс командной строки и выполните winget install wingetcreate, чтобы установить создатель манифеста диспетчера пакетов Windows (Windows Package Manager Manifest Creator Preview). После установки инструмента выполните wingetcreate new и укажите URL-адрес установщика. Затем инструмент загрузит установщик, проанализирует его, чтобы определить любые значения манифеста, доступные в установщике, и проведет вас через процесс создания действительного манифеста. Если вы предоставите свои учетные данные GitHub при появлении запроса, он даже создаст ветвь репозитория, создаст новую ветку, отправит pull request и предоставит вам URL-адрес для отслеживания его прогресса. На изображении ниже показано, как wingetcreate выполняется в Терминале Windows через PowerShell.

Приватные репозитории

И последнее, но не менее важное: мы выпустили эталонную реализацию для источника REST API, чтобы вы могли разместить свой собственный частный репозиторий. Это новый тип источника для диспетчера пакетов Windows. Нашим источником по умолчанию является пакет «PreIndexed», поставляемый через Microsoft Store, но вы можете добавить дополнительные источники на основе REST, если они правильно реализуют схему REST API на основе JSON.

Источник

Альманах пакетных менеджеров Linux

Иногда может возникнуть вопрос: чьих этот файл, откуда вообще взялась эта библиотека? Удобный менеджер пакетов решает очень многие проблемы ОС. Можно с уверенностью сказать, что если вы подружитесь с МП, то подружитесь и с дистрибутивом как таковым. Причем важно освоить именно набор основных команд, и знать где найти дополнительную информацию.

Далее следует джентльменский набор необходимых для повседневной рутины команд основных Linux дистрибутивов: установить, обновить и удалить пакет, накатить обновления, проверить зависимости, установить принадлежность файла пакету и пр.

Debian и родственные

Популярность и образ дружественного к пользователю Linux дистрибутива сыграли с Ubuntu злую шутку. Некоторым новичкам кажется, что можно на нем делать все, что угодно без помощи командной строки. Это заблуждение и лучше от него поскорее избавиться.

Есть еще такое чудо — wajig. Несмотря на странное звучание, вполне годный МП с человеко-читабельным выводом информации на экран.

Настройка репозиториев производится правкой файла /etc/apt/sources.list

В целом ПМ Debian один из лучших, с которыми мне доводилось иметь дело.

Redhat и другие RPM дистрибутивы

Команды rpm на те случаи, когда использовать yum не с руки.

Zypper

На SuSE Linux используется Zypper / YaST для управления пакетами, движок ZYpp крутится поверх RPM.

Можно использовать операторы и регулярные выражения.

Pacman

Этот МП используется в Арче и Manjaro.

Движок поиска в базе данных поддерживает регулярные выражения.

Настройка репозиториев и зеркал производится из файла /etc/pacman.conf

Gentoo emerge

С дополнительными утилитами можно получить больше информации о файлах, ненужных пакетах и т. д.

Источник

Обзор Windows Package Manager: Первая предварительная версия

19 мая 2020 года на онлайн-конференции Build 2020 компания Microsoft представила предварительную версию Windows Package Manager. Администраторы систем Windows могут использовать данный менеджер пакетов для установки продуктов Microsoft и сторонних приложений, таких как 7-Zip, KeePass, Arduino IDE или Discord.

Основная задача инструмента Windows Package Manager — автоматизация процессов установки, обновления и настройки приложений под Windows.

Windows Package Manager работает аналогичным образом, как и системы управления пакетами для Linux или сторонние менеджеры пакетов для Windows, такие как Chocolatey. Microsoft открыла исходный код данного инструмента, поэтому заинтересованные пользователи могут проинспектировать исходники проекта в репозитории GitHub. Там же можно ознакомиться с документацией и загрузить предварительную версию Windows Package Manager.

Первый взгляд на Windows Package Manager

После установки вы можете запустить Windows Terminal, PowerShell или командную строку, чтобы начать пользоваться менеджером пакетов. Запустите команду winget без параметров, чтобы посмотреть доступные команды и справку.

На данный момент Windows Package Manager поддерживает следующие команды:

Команда winget search отображает список программ, которые поддерживает Windows Package Manager. В настоящее время поддерживаются такие популярные программы, как vim, Whatsapp, GIMP, VLC, Steam, Sublime Text, а также многие другие приложения и инструменты для разработчиков.

Обратите внимание, что на данный момент функции удаления не поддерживаются. Microsoft должна в ближайшее время реализовать функции удаления и обновления приложений с помощью менеджера пакетов.

Команда winget install [имя программы] загружает выбранный пакет и запускает установщик. По всей видимости, программы загружаются со сторонних сайтов (сайт разработчика), а не из репозитория, поддерживаемого Microsoft.

Winget показывает расположение файла. Менеджер пакетов в настоящее время поддерживает установщики exe, msi и msix.

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

Команда winget show [имя пакета] отображает дополнительную информацию о программе, например ссылки на домашнюю страницу и лицензию, URL-адрес источника, SHA256 хэш и тип установщика.

Разработчики ПО могут предоставить свои продукты для Windows Package Manager, подробная инструкция представлена на сайте Microsoft Docs. По сути, разработчикам необходимо создать манифест пакета с информацией о приложении. Затем они могут отправить манифест в репозиторий Windows Package Manager на GitHub.

Windows Package Manager поддерживает скрипты. Администраторы могут создавать пакетные сценарии или скрипты PowerShell, например для пакетной установки нескольких приложений.

Например, следующий скрипт устанавливает приложения Microsoft PowerToys и Windows Terminal:

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

А вам понравился Windows Package Manager? Вы будете пользоваться этим инструментом?

Источник

Менеджеры зависимостей

В этой статье я расскажу, в чем менеджеры зависимостей (package manager) схожи по внутреннему устройству, алгоритму работы, и в чем их принципиальные отличия. Я рассматривал package manager’ы, предназначенные для разработки под iOS/OS X, но содержание статьи с некоторыми допущениями применимо и к другим.

Разновидности менеджеров зависимостей

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

Схема проекта при использовании менедежера зависимостей

Рассмотрим на примере популярного package manager’а Cocoapods.
Обычно мы выполняем условную команду pod install, а затем менеджер зависимостей все делает за нас. Рассмотрим, из чего должен состоять проект, чтобы эта команда завершилась успешно.

Все 4 компонента перечислены друг за другом, т.к. последующий компонент формируется исходя из предыдущего.

Не у всех менеджеров зависимостей есть все 4 компонента, но с учетом функций менеджера зависимостей наличие всех — оптимальный вариант.

После установки зависимостей все 4 компонента идут на вход компилятору либо интерпретатору в зависимости от языка.

Также обращу внимание, что за первые две составляющие ответственны разработчики – мы пишем этот код, а за оставшиеся две – сам менеджер зависимостей – он генерирует файл(ы) и скачивает исходный код зависимостей.

Алгоритм работы менеджера зависимостей

С составными частями более-менее разобрались, теперь перейдем к алгоритмической части работы МЗ.

Типовой алгоритм работы выглядит так:

Валидация проекта и среды окружения

Валидация включает проверку версий ОС, вспомогательных утилит, которые необходимы менеджеру зависимостей, а также линтовку настроек проекта и manifest-файла: начиная от проверки на синтаксис, заканчивая несовместимыми настройками.

Возможные предупреждения и ошибки при проверке podfile:

Построение графа зависимостей

Так как у нужных нашему проекту зависимостей могут быть свои зависимости, а у тех в свою очередь — собственные вложенные зависимости или подзависимости, менеджеру использовались корректные версии. Схематично все зависимости в результате должны выстроиться в направленный ацикличный граф.

Построение направленного ацикличного графа сводится к задаче топологической сортировки. У нее есть несколько алгоритмов решения.

Результатом решения является созданный lock-файл, который полностью описывает отношения между зависимостями.

Какие проблемы могут возникать при работе данного алгоритма? Рассмотрим пример: есть проект с зависимостями A, B, E с вложенными зависимостями C, F, D.

Зависимости A и B имеют общую зависимость C. И здесь С должна удовлетворить требованиям зависимости A и B. Какой-то менеджер зависимостей допускает установку отдельных версий, если это необходимо, а cocoapods, например, нет. Поэтому в случае несовместимости требований: A требует версию, равную 2.0 зависимости С, а B требует версию 1.0, установка завершится с ошибкой. А если зависимости A нужна версия 1.0 и выше до версии 2.0, а зависимости B версия 1.2 или менее до 1.0, будет установлена максимально совместимая для A и В версия 1.2. Не стоит забывать, что может возникнуть ситуация циклической зависимости, пусть даже не напрямую – в этом случае установка также завершится с ошибкой.

Рассмотрим, как это выглядит в коде наиболее популярных менеджеров зависимостей для iOS.

Carthage

Реализация Resolver находится тут, а NewResolver тут, Analyzer как такового нет.

Cocoapods

Реализация алгоритма построения графа выделена в отдельный репозиторий. Здесь же реализация графа и Resolver. В Analyzer можно найти, что проверяется соответствие версий cocoapods системы и lock-файла.

Из исходников также видно, что Analyzer генерирует таргеты для зависимостей.

Типовой lock-файл cocoapods выглядит примерно так:

В секции PODS перечисляются прямые и вложенные зависимости с указанием версий, далее подсчитываются их контрольные суммы в отдельности и вместе и указывается версия cocoapods, которая использовалась для установки.

Скачивание зависимостей

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

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

Централизация

Говоря простым языком, менеджер зависимостей имеет два пути при скачивании зависимостей:

Безопасность

Если вы скачиваете зависимости по https или ssh, то можете спать спокойно. Тем не менее, часто разработчики предоставляют http-ссылки на свои официальные библиотеки. И здесь мы можем столкнуться с атакой «человек посередине», когда злоумышленник подменит исходный код, исполняемый файл или фреймворк. Какие-то менеджеры зависимостей не защищаются от этого, а некоторые делают это следующим образом.

Homebrew

Проверка curl в устаревших версиях OS X.

Также есть проверка хэша SHA256 при скачивании по http.

А еще можно запретить небезопасные редиректы на http (переменная HOMEBREW_NO_INSECURE_REDIRECT).

Carthage и Cocoapods

Здесь все попроще – нельзя использовать http на исполняемые файлы.

Swift Package Manager

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

Интеграция зависимостей

Под интеграцией я понимаю подключение зависимостей к проекту таким образом, чтобы мы беспрепятственно могли их использовать, и они компилировались с основным кодом приложения.
Интеграция может быть либо ручной (Carthage), либо автоматической (Cocoapods). Плюсы автоматической – минимум телодвижений со стороны разработчика, но может добавиться много магии в проект.

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

Источник