Каждый автор так или иначе снабжает свои скрипты метаинформацией, такой как название, описание, версия, автор, тема обсуждения на форуме, и т. п.
Сейчас эта информация может содержаться где угодно: в комментариях, или в каком-то диалоге, или в справке.
Естественно централизовано посмотреть её не получится.
Но раз каждый скрипт в любом случае содержит какую-то метаинформацию, то почему бы не заполнять её стандартизировано?
В результате мы получим возможность управлять скриптами централизованно, и реализовать разные интересные возможности, такие как изложенные ранее: http://forum.farmanager.com/viewtopic.p ... 66#p121966
Представляю экспериментальную реализацию некоторых идей:
Основные понятия:
Скрипт — это lua-файл. Он может содержать макросы или выполнять свои функции иным способом.
Скрипт может иметь вспомогательные файлы (cfg/lng/hlf).
Несколько скриптов могут формировать "пакет".
ScriptsBrowser.lua — утилита для работы со скриптами, запускается из меню плагинов.
main.png (24.01 KiB) Viewed 49516 times
sub-scripts.png (11.08 KiB) Viewed 49516 times
Info.png (20.01 KiB) Viewed 49516 times
help.png (25.7 KiB) Viewed 49516 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, или по полному имени файла.
Не пользовался, давайте посмотрим.
(Я сильно не копал, поэтому попробую дофантазировать, а вы поправьте что не так)
Определённо решает вопрос размещения пакетов, и их обновления.
Клиент (nuget.exe) ~ 4 MB, вроде не проблема.
Требует какой-то там дотнет, но на современных ОС тоже не проблема (на XP сходу не запустился).
Вопрос: а что собой представляет база установленных пакетов?
Она общая для системы, или хранится локально?
Будет ли всё работать портабельно, с неустановленными копиями фара?
Из практики использования пользователями я вижу что файлы свободно переименовываются, папки переносятся, и в nuget эту ситуацию никак не обработать.
Т.е. всё нормально, если каждый пакет устанавливается в собственную папку, и создатели пакетов согласовывают их уникальность.
Или можно использовать nuget как хранилище и транспорт, а если хочется большей гибкости, то установку и прочее придётся пилить самостоятельно.
У меня опыта работы с NuGet тоже нет. Просто я читал, что Майкрософт его продвигает как менеджер пакетов, и многие хорошие инструменты (особенно ориентированные на .NET) его поддерживают. Вот бы NightRoman поделился своим опытом…
IgorZ wrote: С одной стороны, автору будет лень писать несколько знаков дополнительно на каждый файл, с другой, ему не лень проделать работу по изучению документации, вставке nfo и, для уже имеющихся проектов, переименованию файлов и соответствующей переделке кода программы.
В конечном счёте всё упирается для чего всё это автору. На мой взгляд установка/обновление/автообновление это наиболее весомые причины.
А что касается заполнения полей.. Ну необязательны они, зачем кого-то заставлять.
Вот посмотрит автор как выглядит его скрипт в браузере, и может наведёт это его на какие-то мысли.
Возвращаясь к вопросу указания типа файла: если это нигде потом не используется, то для чего автору его заполнять? А если зачем-то нужно, значит он мотивирован, и заполнит как надо (или файл переименует).
IgorZ wrote: Файл языка или настроек с расширением .lua - не скрипт по смыслу.
Если они загружаются, то нет проблемы добавить туда Info из 2х строк.
Если нет, то тот же nfo может сейчас содержаться в родительском скрипте, или в специально выделенном файле (как вы и предлагали).
Я не вижу чтобы это противоречило главной идее.
Собственно, принципиальных возражений против того, чтобы изменить формат поля files у меня нет, просто пока необходимости не вижу.
IgorZ wrote: nfo довольно объёмен.
2 строки, ведь необязательно все поля заполнять.
IgorZ wrote: писать их в одном файле по штуке на каждый вспомогательный файл - явно лишне.
Я тоже так решил, потому и предусмотрел поле files.
Info предлагаю писать не на каждый файл, а только там, где реально потребуется.
IgorZ wrote: dbkey = {"GLOBAL","IgorZ","LuaManager"} выглядит не особо элегантно.
А мне нравится)
Но не буду упираться, решать вам, как автору редактора (к нему правда вопросы тоже есть, но это в другой теме)
По формату истории: посмотрим как она у нас будет на практике использоваться.
И стоит ли ей находиться в nfo, это ж громоздко. Может лучше в отдельном файле.
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, например