Каждый автор так или иначе снабжает свои скрипты метаинформацией, такой как название, описание, версия, автор, тема обсуждения на форуме, и т. п.
Сейчас эта информация может содержаться где угодно: в комментариях, или в каком-то диалоге, или в справке.
Естественно централизовано посмотреть её не получится.
Но раз каждый скрипт в любом случае содержит какую-то метаинформацию, то почему бы не заполнять её стандартизировано?
В результате мы получим возможность управлять скриптами централизованно, и реализовать разные интересные возможности, такие как изложенные ранее: http://forum.farmanager.com/viewtopic.p ... 66#p121966
Представляю экспериментальную реализацию некоторых идей:
Основные понятия:
Скрипт — это lua-файл. Он может содержать макросы или выполнять свои функции иным способом.
Скрипт может иметь вспомогательные файлы (cfg/lng/hlf).
Несколько скриптов могут формировать "пакет".
ScriptsBrowser.lua — утилита для работы со скриптами, запускается из меню плагинов.
main.png (24.01 KiB) Viewed 49942 times
sub-scripts.png (11.08 KiB) Viewed 49942 times
Info.png (20.01 KiB) Viewed 49942 times
help.png (25.7 KiB) Viewed 49942 times
regscript.lua — сам модуль, регистрирующий скрипты.
Должен быть подключен в _macroinit.lua: require"regscript"
Чтобы скрипт был зарегистрирован, он должен содержать примерно такой код:
local Info = Info or package.loaded.regscript or function(...) return ... end --luacheck: ignore 113/Info
local nfo = Info { _filename or ...,
name = "<name>";
id = "<unique id string>";
options = {a=1,b=2};
--etc
}
if not nfo then return nfo end
local O = nfo.options
Первая строка гарантирует что скрипт будет работать и без модуля регистрации. ... не просто троеточие, а выражение vararg, в данном случае позволяющее передать имя текущего файла.
Две последние строки тоже важны:
- проверка результата регистрации скрипта позволяет запретить выполнение (в случае несоответствия minfarversion, или когда его выполнение отключено другим образом)
- хранение собственных опций в таблице позволяет изменять их на лету в интерфейсе ScriptsBrowser а также переопределять их начальные значения (см. описание cfgscript.lua)
Все поля на данный момент опциональны, и их список открыт для обсуждения.
Пока предлагаю следующие:
name = "module: regscript.lua";
description = "collects metadata of luamacro scripts";
version = "0.1.1-alpha"; --в формате semver: http://semver.org/lang/ru/
author = "jd";
url = "http://forum.farmanager.com/viewtopic.php?p=121966#p121966";
id = "15660DC2-AE3F-41EE-8057-DC7428195908";
parent_id = ""; --id родительского скрипта
minfarversion = {3,0,0,4743,0}; --при несоответствии скрипт завершится
files = ""; --вспомогательные файлы скрипта
config = function(nfo,name) end; --функция конфигурации
help = function(nfo,name) end; --функция справки
execute = function(nfo,name) end; --функция исполняемая при запуске из ScriptBrowser
options = {}; --таблица с произвольными опциями скрипта
disabled = false; --запрет выполнения скрипта (см. ниже cfgscript.lua)
files
Задавая в поле files вспомогательные файлы скрипта, можно указывать абсолютный путь или путь относительно скрипта.
Поддерживаются переменные окружения.
Путь к Macros\scripts можно задать как ~\.
Шаблон * позволяет подставить имя скрипта, например files = "*_en.hlf;*_ru.hlf;"
options
Таблица с опциями, с указанием значений по-умолчанию. Смысл таблицы в том, что перечисленные опции можно изменить из браузера, а также переназначить во внешнем файле (см. cfgscript.lua)
функции
При запуске получают два аргумента: таблицу информации, и собственное имя в ней
Кроме того несколько полей зарезервированы для внутреннего использования: index, FileName, error, cfg.
Поле error создаётся в случае когда при загрузке обнаружены некорректные данные.
В том числе проверяются типы значений (добавляются только корректные поля).
cfgscript.lua — вспомогательный модуль, позволяющий переопределить начальные настройки скриптов не трогая их исходный код.
Настройки могут читаться либо из базы luamacro (уже работает, но ещё не реализован интерфейс для их записи), либо из заданного файла.
Чтобы прочитать их из файла, следует в _macroinit.lua поместить следующую команду: require"regscript".cfgload(fullpath)
Если fullpath не задан то используется файл Macros\scripts\scriptscfg.
Формат файла такой:
Параметр id обязателен.
Параметр disabled позволяет "отключить" скрипт.
Параметр options позволяет (пере)определить произвольные начальные опции.
Реальные примеры см. в scriptscfg.sample
cfgscript_test.lua — демонстрационный скрипт для иллюстрации того, что регистрация может быть полезна и в произвольных скриптах
Т.е. регистрировать можно не только макрофайлы из scripts, но и модули из modules, и вообще любые скрипты, например запускаемые из командной строки: lua:cfgscript_test.lua
InsertInfo.lua — вспомогательный макрос для вставки в скрипт шаблона с метаинформацией.
P.S.
Интерфейс самого модуля может быть интересен для применения в макробраузерах.
Сейчас он позволяет получить таблицу скрипта по индексу, по id, или по полному имени файла.
John Doe wrote: Установка скриптов из пакета/дистрибутива. На основании Info, плюс допустима кастомная функция.
Чтобы получить информацию о скриптах пакета, их тоже надо загрузить.
И стандартный способ тут не годится, т.к. произойдёт нежелательная "регистрация".
Предполагаю выйти из положения несколько модифицировав шаблон.
Будет так:
У меня опыта работы с NuGet тоже нет. Просто я читал, что Майкрософт его продвигает как менеджер пакетов, и многие хорошие инструменты (особенно ориентированные на .NET) его поддерживают. Вот бы NightRoman поделился своим опытом…
За темой не следил. Если есть конкретные вопросы, пожалуйста.
В FarNet реализовано авто установление и обновление NuGet пакетов. Вернее, для FarNet. Сам он не нужен и пакеты могут содержать что угодно в папках tools\FarHome, FarHome.x64, FarHome.x86. Что там есть, то и будет установлено и будет обновляться корректно.
John Doe wrote: Вопрос: а что собой представляет база установленных пакетов?
Она общая для системы, или хранится локально?
Будет ли всё работать портабельно, с неустановленными копиями фара?
а что собой представляет база установленных пакетов?
Базы как таковой нет. Но для каждого пакета в директорию установки пишется инфо-файл, где записано, что и какие файлы поставлены. То есть инфу собрать можно, если надо.
Будет ли всё работать портабельно, с неустановленными копиями фара?
Думаю, да. Надо только четко скрипту указать, куда ставить. Но я не уверен, что точно понимаю вопрос.
NightRoman wrote: Если есть конкретные вопросы, пожалуйста.
Вот мои вопросы:
* Как в NuGet поддержаны зависимости между пакетами?
* Есть ли автоматическое выкачивание и установка пакета вместе со всеми его зависимостями?
* Есть ли удаление вместе с зависимостями, которыми больше никакой пакет не пользуется?
* Как обстоят дела с одновременной установкой разных версий одного пакета/продукта? (В терминологии могу ошибаться.)
Если вместо ответов или в дополнение к ним дадите ссылки, где эти вопросы освещены более подробно, буду признателен.
* Как в NuGet поддержаны зависимости между пакетами?
Поддержаны, прописано в нужных файлах описания пакета.
* Есть ли автоматическое выкачивание и установка пакета вместе со всеми его зависимостями?
У меня в скрипте для Фара нет. Не надо было.
А так зависит от клиента (мой скрипт - пример клиента). NuGet.exe не единственный (и он не обязателен, пример - мой скрипт). Еще есть paket.exe, более продвинутый в некоторых смыслах.
* Есть ли удаление вместе с зависимостями, которыми больше никакой пакет не пользуется?
Сомневаюсь. Это неоднозначная операция.
* Как обстоят дела с одновременной установкой разных версий одного пакета/продукта? (В терминологии могу ошибаться.)
Ответ зависит от многих неизвестных. Что-то можно, что-то нет.
Технологии уже много лет. Я не могу все рассказать тут. И я даже не спец. Google, мануалы по NuGet.
Еще добавлю. Скрипт годится для любых плагинов или чего угодно, что ставится в папку Фара (или указанную). Задача плагинописателя просто упаковать по определенной схеме и выложить на NuGet.
Для макросов можно доработать, если кто-то будет пользоваться. Их ведь надо в другую папку ставить, как я понимаю. Можно и так использовать, конечно, но папку макросов явно указывать и паковать с прицелом на это.
Или доработать скрипт для специальной папки tools\FarProfile и обрабатывать ее в скрипте особым образом, копируя/обновляя в %FARPROFILE%. Но тут не все гладко идеологически. Эта папка может и меняться в зависимости от настроек Фара.
Last edited by NightRoman on Tue 30 Aug, 2016 13:50, edited 1 time in total.
На работе перекинули на другой фронт, пришлось на ходу учиться просить и пиэльэскюэлить. Вот, чуть освободился и сделал то, о чём говорили когда-то.
John Doe wrote:
IgorZ wrote: Имеет ли смысл вводить поле - адрес данных скрипта в БД LuaMacro? Просто, если оно есть, то имеет смысл сделать переход по ссылке - скажем, с помощью DBEdit. Он, правда, пока не вызывается как модуль, но это нетрудно добавить.
Хорошая мысль.
Поле можно назвать dbkey.
А как будем передавать адрес? строкой? таблицей?
Заодно возникла пара вопросов в связи с добавлением в скрипт nfo.
1. А что, minfarversion нельзя задавать строкой? Почему?
2. Задал minfarversion = {3,0,0,4000}. Перезагрузил макросы, запустил ScriptBrowser, DBEdit подсвечен серым. Встаю на него, нажимаю F3, получаю
.
Что, пропускать часть позиций нельзя и надо обязательно указывать все пять чисел? Даже если так, всё равно некрасиво - надо перехватывать такие ситуации.
IgorZ wrote: 1. А что, minfarversion нельзя задавать строкой? Почему?
Соответствующие функции работают с таблицей, отсюда и таблица. Синтаксически таблица не сложнее строки, но строку пришлось бы всё равно конвертировать в таблицу, для обеспечения возможности сравнения версий.
Впрочем, если подумать, не очень сильный аргумент..
Если у вас есть доводы в пользу строки, то почему бы и нет.
Но меня тут смущает один момент: исторически в версии фара не используется компонент Revision, что можно увидеть например в заголовке окна фара.
Поэтому не очень понятно, какой должна быть строка.
В текущей неопубликованной версии ScriptManager minfarversion в окне информации отображается так же без Revision, например
IgorZ wrote: Что, пропускать часть позиций нельзя и надо обязательно указывать все пять чисел? Даже если так, всё равно некрасиво - надо перехватывать такие ситуации.
Согласен, падать не должно.
Насчёт 5 или 4 чисел даже не задумывался, не вручную заполняю а шаблоном.
Принимать и 4?
По факту в нашем случае достаточно и одной (билда), и врядли это когда-то изменится
IgorZ wrote: 1. А что, minfarversion нельзя задавать строкой? Почему?
Соответствующии функции работают с таблицей, отсюда и таблица. Синтаксически таблица не сложнее строки, но строку пришлось бы всё равно конвертировать в таблицу, для обеспечения возможности сравнения версий.
Впрочем, если подумать, не очень сильный аргумент..
Если у вас есть доводы в пользу строки, то почему бы и нет.
Соображение одно: версию скрипта можно задавать строкой, а требуемую версию Far - нет. Разные подходы вызывают недоумение. Однообразие было бы эстетически приятнее (кстати, я, вроде бы, ранее предлагал версию скрипта задавать таблицей - тоже вариант единообразия). Собственно, тоже, если подумать, не очень сильный аргумент..
John Doe wrote:Но меня тут смущает один момент: исторически в версии фара не используется компонент Revision, что можно увидеть например в заголовке окна фара.
Поэтому не очень понятно, какой должна быть строка.
В текущей неопубликованной версии ScriptManager minfarversion в окне информации отображается так же без Revision, например
Думаю, в случае версии Far строка должна соответствовать принятому нумерованию версии Far. Оно уже давно устоялось и вряд ли когда изменится.
John Doe wrote:
IgorZ wrote: Что, пропускать часть позиций нельзя и надо обязательно указывать все пять чисел? Даже если так, всё равно некрасиво - надо перехватывать такие ситуации.
Согласен, падать не должно.
Насчёт 5 или 4 чисел даже не задумывался, не вручную заполняю а шаблоном.
Принимать и 4?
А зачем там пятая, если по факту в Far она не используется в принципе? Оставить для совместимости, если надо, только вставить, где нужно, что-то вроде ver[5] = ver[5] or 0.
John Doe wrote:По факту в нашем случае достаточно и одной (билда), и врядли это когда-то изменится
При переходе с Far1 на Far2 счётчик билдов сбросился, а по макросам совместимость осталась. Так что, думаю, на всякий случай, все четыре лучше бы оставить, и, заодно, сверять по всем позициям. Да и смотрится красивее и понятнее, когда есть все четыре числа.
IgorZ wrote: версию скрипта можно задавать строкой, а требуемую версию Far - нет. Разные подходы вызывают недоумение.
Разные подходы тут неизбежны, поскольку semver невозможно в точности сопоставить VersionInfo, хотя бы по причине структурных отличий (куда накладываются ещё и исторические особенности использования в фаре).
IgorZ wrote: и, заодно, сверять по всем позициям.
Думал об этом, но счёл непринципиальным, ведь элементарно изменить в любой момент.
IgorZ wrote: Думаю, в случае версии Far строка должна соответствовать принятому нумерованию версии Far. Оно уже давно устоялось и вряд ли когда изменится.
Я как раз обратил внимание, что в фаре "принято" использовать 3 компонента, а не 4.
Но только для отображения, а в апи у нас да, честный VersionInfo.
Хотите указывать VersionInfo строкой? Если для вас это принципиально, то я не буду возражать.
И насчёт того чтобы компонент Stage принимать по умолчанию за 0 тоже.
Хотя и не вижу от всего этого никакой особой выгоды, ведь всё это вставляется шаблоном.
Делать?
IgorZ wrote: версию скрипта можно задавать строкой, а требуемую версию Far - нет. Разные подходы вызывают недоумение.
Разные подходы тут неизбежны, поскольку semver невозможно в точности сопоставить VersionInfo, хотя бы по причине структурных отличий (куда накладываются ещё и исторические особенности использования в фаре).
Ну, не знаю. Мне глаз царапнуло, я и задал вопрос.
John Doe wrote:
IgorZ wrote: и, заодно, сверять по всем позициям.
Думал об этом, но счёл непринципиальным, ведь элементарно изменить в любой момент.
Так текущий момент ничем не отличается в этом смысле от любого другого.
Возможно, это просто разные привычки. Я когда-то довольно много писал на ассемблере (в том числе игры), так что привычка заранее предусматривать и закрывать возможные дыры осталась с тех времён.
John Doe wrote:
IgorZ wrote: Думаю, в случае версии Far строка должна соответствовать принятому нумерованию версии Far. Оно уже давно устоялось и вряд ли когда изменится.
Я как раз обратил внимание, что в фаре "принято" использовать 3 компонента, а не 4.
Но только для отображения, а в апи у нас да, честный VersionInfo.
Хотите указывать VersionInfo строкой? Если для вас это принципиально, то я не буду возражать.
И насчёт того чтобы компонент Stage принимать по умолчанию за 0 тоже.
Хотя и не вижу от всего этого никакой особой выгоды, ведь всё это вставляется шаблоном.
Делать?
Непринципиально. Более того, версия скрипта, на мой субъективный взгляд, тоже красивее смотрелась бы в виде таблицы. А вот отсутствующие элементы таблицы принимать за 0 было бы, на мой взгляд, разумно.
P. S. Лично я шаблоном при вставке не пользовался. Возможно, из-за того, что вставка nfo для меня пока ещё больше эксперимент, а не вошла в привычку.