Acts As Librarity или библиотечность


#1

Не покидает меня ощущение, что необходимо наращивать определенное количество библиотек, причем мне до конца непонятно внутренних или внешних.

Например из последнего:

у меня привычка указывать аргументы командой строки в *nix стили
например

 $oscript ./configure.os --v8user=<you account on users.v8.1c.ru> --v8pass=<you password on users.v8.1c.ru> --v8version="latest" 

в этом случае на стороне скрипта я уже хочу иметь Структуру:

параметрыЗапуска.v8user
параметрыЗапуска.v8pass
параметрыЗапуска.v8version

вот вчера и пришлось писать свой парсер по работе со стороками через всякие СтрЗаменить и Лев() Прав().

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

Сейчас конечно есть конструкция ПодключитьСценарий, но дело касается НЕ её, а именно как наращивать некую коллекцию commons библиотек

тот же пакетный запуск Конфигуратора - сейчас если мне нужно для личных целей запустить конфигуратор - скажем для синтаксического контроля, то вместо

_конфигуратор = ПодключитьУправлениКонфигуратором();
_конфигуратор.СинтаксическийКонтроль("d:\infobase\", "8.3.5");

http://dev.silverbulleters.org/deployers/vanessa-ide-batcher

Мне почти полностью приходится копировать код из https://github.com/xDrivenDevelopment/AutoAdmin1C/blob/develop/Scripts/retrieve_storage.os в части формирования командной строки на запуск (а еще ко всему процему у меня еще и Windows/Linux) короче муторно это, и что самое главное, не повторно используемо.

Но проблемы еще и втом, что нет экосистемы для библиотек:

  1. нет npm, gem, pip
  2. нет рекомендаций где их публиковать - то есть аналога rubygems.org

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

то есть если закончить делится, то видится следующая конструкция:

  1. в 1Script должен появится внутренний пакетный менеджер
  2. все библиотеки живут уже отдельными проектами.

в итоге получается 2 блока размера epic:

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

  2. создать типовой конфигурационный файл
    что-нибудь типа такого:

    lib “Управление командной строкой запуска 1С” {
    id: comandliner
    github: http://github/alustin/1script-onec-comandliner
    minver: 0.2
    }

вот такие мысли


#2

Есть v8runner и я планирую его развивать именно, как повторно используемый класс.

Ссылка для ознакомления, пока нигде не выкладывал https://dl.dropboxusercontent.com/u/79336477/v8runner.os


#3

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


#4

@EvilBeaver - заменю ссылку пока не забыл https://github.com/EvilBeaver/oscript-library/blob/develop/src/v8runner/v8runner.os