@Delphinum7 июн 2015 в 08:42

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

7 мин

27K

VIM * Веб-разработка *

+16

Комментарии 31

@glagola 7 июн 2015 в 11:45

Уважаю вас за то, что не бросили попытки подружиться с vim'ом, а подружились и даже стали его менять под себя. У меня есть предложение для вашей экосистемы — сделайте/адаптируйте существующий пакетный менеджер, так чтобы любой плагин по зависмостям вытягивал все необходимые для его работы плагины определенных версии. В программировании такие уже используются (composer, npm, bower и т.д.). Потом на основании зависимостей строилась последовательность загрузки плагинов.

@Delphinum 7 июн 2015 в 11:51

Реализовать это не сложно, если только плагины будут включать некоторый стандартизированный файл зависимостей (как composer.json, package.json и т.д.). Сейчас все глагины, которые реализованы с использованием sys/Plugin, при их объявлении включают имя, зависимости и версии, сделано это как раз для разрешения зависимостей в будущем.

Пример

let s:p = s:Plugin.new('vim_unittest_phpunit', '1', {'plugins': ['vim_unittest']}) " Имя, версия, список зависимостей

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

@glagola 7 июн 2015 в 11:59

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

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

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

@Delphinum 7 июн 2015 в 12:03

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

@glagola 7 июн 2015 в 12:07

У меня просто душа радуется, когда я могу зайти в проект и набрать:

composer install
bower install
npm install

А не делать это все в ручную

@Delphinum 7 июн 2015 в 17:45

Сказано — сделано. Реализовал простенький механизм автоматического разрешения зависимостей. Теперь, если в плагине будет присутствовать файл plugman.vim с перечислением зависимостей:

Пример

{
  'name': 'vim_unittest_phpunit',
  'requires': {
    'Bashka/vim_unittest': '1'
  }
}

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

@ZyXI 8 июн 2015 в 20:28

А моцжет всё‐таки использовать уже существующий addon-info.json (https://bitbucket.org/vimcommunity/vim-pi-documentation)? Вообще я был бы рад, если бы vim-pi у меня кто‐то забрал, всё равно проект довольно заброшен и я не знаю, когда к нему вернусь.

@Delphinum 8 июн 2015 в 20:43

А почему забросили, если не секрет?

@ZyXI 8 июн 2015 в 20:52

Особо отдачи нет. Основная проблемы:

Не умею и не хочу заниматься рекламой. Так что кроме NeoBundle и VAM vim-pi никто не использует.
VAM имеет мало пользователей не в последную очередь из‐за документации. Я умею и люблю писать подробную и достаточно структурированую документацию… для разработчиков. MarcWeber любит писать различные tips-and-tricks и превращать документацию в помойку: tips-and-tricks полезные, но структурированность хромает. Документацию для новичков не умеет писать в проекте никто. Ещё у меня есть подозрение, что та же беда с UI. Т.е. закончить, наконец, новый вариант vim-pi я могу: там не так уж много вроде осталось. А вот изменять VAM под это дело как‐то не хочется, т.к. всё равно им мало кто пользуется.
Есть другие проекты: viml-to-lua translator, powerline, мои собственные дополнения.
Учёба на вечернем факультете, совмещённая с работой.

@ZyXI 8 июн 2015 в 20:58

И, ещё одно: методология разработки, используемая MarcWeber (вроде называется «экстремальная разработка» или как‐то так). Я не могу относится серьёзно к дополнению, у которого нет релизов, даже если я его соавтор.

@Delphinum 8 июн 2015 в 20:59

А почему вы считаете, что я смогу решить эти проблемы? )

@ZyXI 8 июн 2015 в 21:05

Зачем‐то же вы написали здесь статью
У вас свой менеджер дополнений.

Учитывая, что скоро сессия закончится, я могу и доделать, наконец, новый репозиторий vim-pi. Если он кому‐то нужен.

Но формат addon-info.json слишком радикально меняться не собирается. Так что если вы хотите иметь зависимости, то логично использовать его, а не изобретать ещё‐один‐стандарт. Сам plugin index уже содержит информацию о зависимостях помимо распространяемой с некоторыми дополнениями, так что начинать будете не с нуля, в новый plugin index она точно перекочует.

@Delphinum 8 июн 2015 в 21:11

Я готов использовать addon-info.json, но так как еще очень плохо знаком с ним, то полноценно перенять ваш труд и отвечать за дальнейшее развитие стандарта я пока не смогу.

@JagaJaga 7 июн 2015 в 19:17

Уже это реализовано. Взглляните сюда github.com/MarcWeber/vim-addon-manager, в частностии на пункт github.com/MarcWeber/vim-addon-manager#how-does-vam-know-about-dependencies.

К тому же, VAM умеет очень многое. Самое полезное — это вызов плагинов при определенном расширении файла.

@Delphinum 7 июн 2015 в 19:52

Ну увидел там описания механизма автоматического разрешения зависимостей.

А VAM умеет устанавливать и считывать плагины, установленные в проектный каталог (на пример ./.vim/bundle, а не ~/.vim/bundle) и учитывать порядок загрузки плагинов (саначала корневые, потом зависимые)?

Самое полезное — это вызов плагинов при определенном расширении файла

Вы про ftplugin?

@Delphinum 7 июн 2015 в 19:56

Ну = Не*

@ZyXI 8 июн 2015 в 20:36

Во‐первых, не умеет в проектный каталог. Во‐вторых, можно и ftplugin, и вообще любое событие (autocommand). Просто для каких‐то событий уже есть код, который вызывает vam#ActivateAddons когда нужно.

Разрешение зависимостей есть: определяется порядок активации (либо добавления в &rtp, либо добавления и «ручного» запуска скриптов и событий), при установке подтягиваются зависимости, если о них известно. Возможности указать требуемую версию нет, должна быть в декларативном виде в vim-pi, если я, наконец, до неё доберусь (сейчас там в документации почему‐то даже нет описания ключа «dependencies», а VAM его знает и любит).

@Beyondtheclouds 8 июн 2015 в 08:20

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

А можешь привести пару примеров(реальных из практики) в которых вот прям было больно из за менеджера плагинов?

@Delphinum 8 июн 2015 в 11:02

Да, конечно. Представьте ситуацию, когда у вас есть некий плагин, который установлен в вашем ~/.vim/bundle и настроен в ~/.vimrc, но вы хотите переопределить его настройки для конкретного проекта в myProject/.vimrc. Проблема в том, что загрузка этого плагина выполняется после загрузки myProject/.vimrc, что делает невозможным переопределение. Другими словами, все известные менеджеры, которые я встречал, нарушали принятый в Vim порядок загрузки плагинов — сначала rc, затем plugin, затем ftplugin, затем after и все согласно уровням иерархии. Обычно плагины просто добавляются в конец runtimepath.

Другой пример я описал в статье. Что делать, если мне нужно установить плагин именно в конкретный проект, а не в ~/.vim/bundle?

@Beyondtheclouds 8 июн 2015 в 13:31

Да, конечно. Представьте ситуацию, когда у вас есть некий плагин, который установлен в вашем ~/.vim/bundle и настроен в ~/.vimrc, но вы хотите переопределить его настройки для конкретного проекта в myProject/.vimrc. Проблема в том, что загрузка этого плагина выполняется после загрузки myProject/.vimrc, что делает невозможным переопределение. Другими словами, все известные менеджеры, которые я встречал, нарушали принятый в Vim порядок загрузки плагинов — сначала rc, затем plugin, затем ftplugin, затем after и все согласно уровням иерархии. Обычно плагины просто добавляются в конец runtimepath.

Я потому и спросил из практики случай, с которым было больно, с названиями и всем таким :) Описанную проблему я понял, но на практике не сталкивался с болью в этом месте, хотя в виме работаю очень много и активно:)

Другой пример я описал в статье. Что делать, если мне нужно установить плагин именно в конкретный проект, а не в ~/.vim/bundle?

не могу представить ситуацию когда это оправдано. (no offence, просто пытаюсь понять есть ли в этом месте боль)

@Delphinum 8 июн 2015 в 13:37

Я потому и спросил из практики случай, с которым было больно, с названиями и всем таким :) Описанную проблему я понял, но на практике не сталкивался с болью в этом месте, хотя в виме работаю очень много и активно:)

Ну вы же спросили о моем практическом опыте, а не о своем. Возможно вы с таким не сталкивались, а вот я уже не раз.

не могу представить ситуацию когда это оправдано

Хочу использовать во всех моих проектах на Java для сборки gradle, а один вынужден собирать на каком нибудь Ant. Зачем мне ставить адаптер под Ant всем проектам, когда могу поставить его только одному.
Хочу в одном из проектов использовать ctags, а в других нет. Если поставлю плагин в ~/.vim/bundle, все крупные проекты начнут подвисать.

@Beyondtheclouds 8 июн 2015 в 15:50

Ну вы же спросили о моем практическом опыте, а не о своем. Возможно вы с таким не сталкивались, а вот я уже не раз.

Так и не ответили, с какими плагинами и в какой ситуации в этом месте были проблемы :)

Хочу использовать во всех моих проектах на Java для сборки gradle

На мой взгляд странный флоу, но в приницпе кейс понятен :)

@Delphinum 8 июн 2015 в 16:49

Так и не ответили, с какими плагинами и в какой ситуации в этом месте были проблемы :)

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

На мой взгляд странный флоу, но в приницпе кейс понятен

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

@Beyondtheclouds 8 июн 2015 в 16:55

Во, теперь понятно :) спасибо.

@ZyXI 8 июн 2015 в 20:43

Я для этого использую localrc. Большинство дополнений нормально переносят настройку после запуска plugin/**/*.vim.

@Delphinum 8 июн 2015 в 20:46

Ну вы же все плагины и конфиги не складываете в ваш .vimrc, так зачем же делать это в localrc?

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

@ZyXI 8 июн 2015 в 20:42

VAM учитывает after при добавлении в &runtimepath. Загрузка rc не в его ответственности, plugin/ftplugin/after загружаются Vim и только если активация происходит после VimEnter VAM’у приходится брать на себя ответственность и загружать {,after/}{plugin,ftplugin,syntax}.

@Delphinum 8 июн 2015 в 20:49

Но обычно менеджеры плагинов просто добавляют все имеющиеся в .vim/bundle/ каталоги в runtimepath, в результате загрузка выполняется в следующем порядке:
Базовые скрипты Vim
~/.vimrc
~/.vim/plugin/
./.vimrc
./.vim/plugin/
~/.vim/bundle/
что не есть правильно.

@ZyXI 8 июн 2015 в 20:55

Где вы такие менеджеры дополнений видели? У большинства вроде требуется написать список дополнений в vimrc. Кстати, в случае с VAM вполне можно написать список дополнений в vimrc и ещё один в localrc. Здесь абсолютно не нужно пихать дополнение в каталог проекта, оно всё равно не загрузится, пока не появится в аргументе vam#ActivateAddons().

@ZyXI 8 июн 2015 в 20:56

Но, конечно, не все, как VAM, заботятся о правильном порядке дополнений в runtimepath.

@Delphinum 8 июн 2015 в 21:01

Написать то список требуется, но этот список никак не определяет, в какую точку runtimepath будут добавляться эти дополнения, а добавляются они обычно с помощью runtimepath += плагин.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий