Vi package manager что это

Что такое диспетчер пакетов в Linux? Как это работает?

Vi package manager что это

Одним из основных отличий дистрибутивов Linux друг от друга является управление пакетами. В этой статье вы узнаете о пакетах и ​​менеджерах пакетов в Linux. Вы узнаете, что такое пакеты, что такое менеджеры пакетов, как они работают и какие менеджеры пакетов доступны.

Что такое диспетчер пакетов в Linux?

Проще говоря, менеджер пакетов – это инструмент, который позволяет пользователям устанавливать, удалять, обновлять, настраивать и управлять пакетами программного обеспечения в операционной системе. Менеджер пакетов может быть графическим приложением, таким как программный центр, или инструментом командной строки, таким как apt-get или pacman .

Что такое пакет?

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

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

Сценарий настройки или зачастую включаемый make-файл.

Вам придется скомпилировать программное обеспечение или самостоятельно или вместе со всеми зависимостями (для некоторых программ требуется установка другого программного обеспечения) самостоятельно.

Чтобы избавиться от этой сложности, дистрибутивы Linux создали свой собственный формат упаковки, чтобы предоставить конечным пользователям готовые к использованию двоичные файлы (предварительно скомпилированное программное обеспечение) для установки программного обеспечения вместе с некоторыми метаданными (номер версии, описание) и зависимостями.

Это как испечь торт, а не купить торт.

Примерно в середине 90-х Debian создал формат упаковки .deb или DEB, а Red Hat Linux создал систему упаковки .rpm или RPM (сокращение от Red Hat Package Manager). Компиляция исходного кода все еще существует, но теперь это необязательно.

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

Как работает менеджер пакетов?

Имейте в виду, что менеджер пакетов – это общая концепция, а не только для Linux. Вы часто найдете менеджер пакетов для разных программ или языков программирования. Только для пакетов Python есть менеджер пакетов PIP . Даже в редакторе Atom есть собственный менеджер пакетов.

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

Я создал эту диаграмму (на основе SUSE Wiki), чтобы вы могли легко понять, как работает менеджер пакетов.

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

В репозиториях также есть файлы метаданных, которые содержат информацию о пакетах, такую ​​как имя пакета, номер версии, описание пакета и имя репозитория и т. д. Это то, что вы увидите, если используете команду apt show в Ubuntu / Debian.

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

Когда вы запускаете команду установки вашего менеджера пакетов (например, apt install package_name), менеджер пакетов обращается к этому кешу. Если он находит информацию о пакете в кэше, он использует подключение к Интернету для подключения к соответствующему репозиторию и сначала загружает пакет перед установкой в ​​вашу систему.

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

Диспетчер пакетов, обрабатывающий зависимости в Linux

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

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

Различные типы менеджеров пакетов

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

Например, в RPM есть менеджеры пакетов Yum и DNF . Для DEB у вас есть менеджеры пакетов на основе командной строки apt-get, aptitude.

Менеджер пакетов Synaptic

Менеджеры пакетов не обязательно основаны на командной строке. У вас есть графические инструменты управления пакетами, такие как Synaptic . Программный центр вашего дистрибутива также является менеджером пакетов, даже если он запускает под ним apt-get или DNF.

Вывод

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

Я пока пропустил новые универсальные форматы упаковки, такие как Snap и Flatpak.

Я очень надеюсь, что вы немного лучше понимаете систему управления пакетами в Linux. Если вы все еще не уверены или у вас есть вопросы по этой теме, воспользуйтесь системой комментариев. Я постараюсь ответить на ваши вопросы и, если потребуется, дополню эту статью новыми моментами.

Источник: https://zen.yandex.ru/media/id/5bcf8be364de8e00aa32d62b/chto-takoe-dispetcher-paketov-v-linux-kak-eto-rabotaet-5fa5f1ff8eb5b23a30cee728

Vim по полной: Менеджер плагинов без фатальных недостатков

Vi package manager что это

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

Плохие Другие менеджеры

Как работает менеджер плагинов для Vim? Все тривиально. Во время старта редактора считывается .vimrc в котором объявляются все используемые в данный момент плагины.

Эти имена конкатенируются с адресом каталога, который должен хранить плагины и полученные строки добавляются в runtimepath — переменная Vim, которая определяет, откуда редактору брать стартовые скрипты, плагины и все остальное.

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

К чему это ведет? Плагины загружаются беспорядочно, нет возможности переопределить настройки плагина для конкретного проекта, плагины переопределяют ваши собственные настройки Vim и т.д. Все еще больше усугубляется невозможностью контролировать порядок загрузки плагинов, когда нужно сначала загрузить плагин A, а только затем зависимый от него благин B. Одним словом — боль.

Что нам нужно в идеале

Я уже говорил раньше и подробнее остановлюсь на этом вопросе в следующей статье, а сейчас только немного коснусь его. Предлагаемая мной структура добавляет еще один уровень инициализации редактора Vim.

Это означает, что ваши Vim-конфигурации и плагины будут существовать на трех уровнях:

  1. Системном ($VIMRUNTIME/) — конфигурации и плагины, которые распространяются на всех пользователей системы
  2. Пользовательские (~/.vim/) — конфигурации и плагины конкретного пользователя
  3. Проектные (./.

    vim/) — конфигурации и плагины, доступные только в данном проекте. Именно этого уровня нет в Vim, точнее он есть, но реализован довольно слабо

Это позволит, например, настроить шаблоны для Java классов, а затем переопределить их для конкретного проекта.

Можно так же установить некоторый плагин только для определенного проекта, и этот плагин не будет подгружаться Vim в других проектах, что сэкономит память и увеличит производительность редактора (например вы решили начать работать с Lua и не хотите ставить плагины в ~/.vim/). Только представьте, один редактор на все случаи жизни и никаких лагов.

Стандарты плагинов

Библиотека vim_lib определяет как структуру плагинов Vim (но не ограничивает вас только этой структурой, может использоваться любой плагин), так и порядок их подключения и загрузки, для этого реализованы классы sys/Plugin и sys/Autoload соответственно.

Если реализовать плагин в строгом соответствии с требованиями класса sys/Plugin, то мы получим следующую структуру:

myPlugin/ plugin/ myPlugin.vim autoload/ … myPlugin.vim doc/ myPlugin.rux
Файл plugin/myPlugin.vim содержит логику инициализации и подключения плагина.
Пример” Date Create: 2015-02-23 22:45:56″ Last Change: 2015-06-07 18:21:15″ Artur Sh. Mamedbekov (Artur-Mamedbekov@yandex.ru)” License: GNU GPL v3 (http://www.gnu.org/copyleft/gpl.html) ” Аналог use в VimLanguagelet s:Plugin = vim_lib#sys#Plugin#let s:System = vim_lib#sys#System#.new() let s:p = s:Plugin.new('vim_write', '1') ” Создание объекта плагина с указанием его имени и версии ” Опции плагина”” {{{” @var bool Следует ли выполнять замену ключевых значений в файле перед сохранением.”” }}}let s:p.preplace = 1″” {{{” @var bool Включен ли механизм автосохранения изменений.”” }}}let s:p.aw = 0″” {{{” @var string|array Массив, содержащий имена типов файлов, для которых задействован механизм автосохранения изменений. Если опция установлена в значение 'all', механизм задействован для всех типов файлов.”” }}}let s:p.awTypes = 'all'if !exists('g:vim_write#replacement') “” {{{ ” @var hash Словарь замен, используемый перед записью буфера для замены ключевых слов. Словарь имеет следующую структуру: {типФайла: [regexp, …]}. Тип 'all' используется для всех файлов. “” }}} let g:vim_write#replacement = {}endif ” Функция инициализации плагина, в ней можно писать любую логикуfunction! s:p.run() ” {{{ call s:System.au('BufWritePre,FileWritePre', function('vim_write#_writePre')) call s:System.au('CursorHold', function('vim_write#_autowrite'))endfunction ” }}} ” Объявление пунктов меню плагина. Они попадут в Plugins.имяПлагина.пунктМенюcall s:p.menu('Aw_start', 'awstart', '1')call s:p.menu('Aw_stop', 'awstop', '2') ” Объявление команд плагинаcall s:p.comm('VimWriteAwStart', 'awstart()')call s:p.comm('VimWriteAwStop', 'awstop()') call s:p.reg() ” Регистрация плагина, которая делает его доступным в редакторе

Файл autoload/myPlugin.vim содержит методы плагина. Опытные пользователи Vim сразу заметят, что основной код плагина будет подгружаться при первом его использовании, а не во время запуска редактора. Делается это через глобальный вызов методов плагина. На пример, при выполнении команды VimWriteAwStart из предыдущего примера, будет вызван метод имяПлагина#awstart().
Пример” Date Create: 2015-02-23 22:48:37″ Last Change: 2015-06-07 18:21:15″ Artur Sh. Mamedbekov (Artur-Mamedbekov@yandex.ru)” License: GNU GPL v3 (http://www.gnu.org/copyleft/gpl.html) ” Аналог use в VimLanguagelet s:Publisher = vim_lib#sys#Publisher#.new()let s:Content = vim_lib#sys#Content#.new() “” {{{ ” Метод активирует механизм автосохранение.”” }}}function! vim_write#awstart() ” {{{ let g:vim_write#.autowrite = 1endfunction ” }}} …

Файл doc/myPlugin.rux содержит документацию к плагину. Зачем все это нужно? Во-первых стандартизация. Писать, изменять и разбираться в плагинах становится легче. Во-вторых их проще отключить.

Подробнее можно почитать здесь.

Автозагрузка

Класс sys/Authoload библиотеки определяет порядок инициализации как самого редактора Vim, так и его плагинов.

Инициализация выполняется в несколько этапов:

  1. Подключение основных файлов конфигурации редактора ($VIMRUNTIME)
  2. Подключение общесистемных плагинов ($VIMRUNTIME/plugin/)
  3. Подключение файло-зависимых конфигураций ($VIMRUNTIME/ftplugin/)
  4. Подключение основных файлов конфигурации пользователя (~/.vimrc)
  5. Подключение пользовательских плагинов (~/.vim/plugin/)
  6. Подключение файло-зависимых плагинов пользователя (~/.vim/ftplugin/)
  7. Подключение основных файлов конфигурации проекта (./.vimrc)
  8. Подключение проектных плагинов (./.vim/plugin/)
  9. Подключение файло-зависимых плагинов проекта (./.vim/ftplugin)

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

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

Для использования автозагрузки, предлагаемой классом sys/Authoload, достаточно добавить в ваш файл .vimrc следующие строки:

filetype off set rtp=~/.vim/bundle/vim_libcall vim_lib#sys#Autoload#init('~/.vim', 'bundle') ” Адрес до вашего ~/.vim/bundle Plugin 'vim_lib'” Другие плагины filetype indent plugin on
Сделать это можно не только на пользовательском уровне (~/.vimrc), но и на системном ($VIMRUNTIME/.vimrc) или проектном (./.vimrc), при этом логика автозагрузки будет распространятся только от данного уровня и «ниже». На всех низлежайших уровнях достаточно просто подключать новые плагины, доступные только этому уровню:
filetype off call vim_lib#sys#Autoload#init('.vim', 'bundle') ” Подключение плагина на проектном уровнеPlugin 'myPlugin'filetype indent plugin on
Для отключения плагина, достаточно просто закоментировать строку Plugin 'имя'. Сконфигурировать плагин можно прямо во время его подключения:Plugin 'vim_deploy', { \ 'options': {'adapter': 'shipit'}, ” Переопределение опций плагина \ 'map': {'deploy': 'd'}, ” Переопределение горячих клавиш \} На более низких уровнях можно переопределить эти конфигурации:let g:vim_deploy#options = {'adapter': 'gradle'} Все очень гибко и удобно.

Менеджер плагинов

Казалось бы, что мешает заставить другие менеджеры плагинов устанавливать плагины в нужные нам каталоги (системный, пользовательский или проектный)? Проблема здесь в том, что другие менеджеры не просто устанавливают сторонние плагины, но и определяют порядок из инициализации, а нам это не нужно (уже реализовано классом sys/Authoload библиотеки). Та самая проблема несовместимости Vim плагинов, о которой я говорил в предыдущей статье. Пришлось писать свое решение.

vim_plugmanager имеет довольно простой интерфейс и позволяет устанавливать плагины из GitHub в системный каталог, каталог пользователя или проектный каталог, в зависимости от того, где вы сейчас находитесь.

Окно со списком плагинов

Как видно на рисунке, vim_plugmanager реализован в виде окна, в котором он отображает список установленных на данный момент плагинов (именно установленных, а не подключенных) с группировкой по уровням. Для добавления нового плагина достаточно нажать клавишу a, а для удаления навести курсор на плагин и нажать dd (очень привычно, не так ли?).

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

vimrc (текущего уровня) запись Plugin 'имяПлагина'.

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

Подробнее можно почитать здесь.

Пока все

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

Не думаю, что стоит копировать документацию, когда она доступна в общем доступе.

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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

  • 3,2%

Источник: https://habr.com/ru/post/259725/

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.