Формат описания packagedef

[khorevaa]

Как разработчик хочу иметь возможность указывать настройки пакета в формате yaml
Пример файла ниже

name: YAML 
version: 0.0.1
description: Конвертация и чтение в формат YAML
executable: 
    class: 'yaml2.os'
engine-version: '*'
include-content:
    - 'src/*'
    - 'tests/*'
    - 'bin/*'
    - readme.md
explicit-modules:
    - '*'
keywords:
    - null
repository:
    type: git
    url: ..
author:
    name: Автор
    email: Почта
    url: url
depends-on:
    logos: 1.1.0
    cmdline: ^3.0.6
    tempfiles: '^3.4.3"'
    tool1cd: ^2.0.0
    v8runner: ^4.0.0
    strings: '*'

[nixel2007]

Это вопрос к @EvilBeaver. Он изначально хотел, чтобы описание пакета было 1сным кодом.
Я предлагал json, но встретил сопротивление :)

[EvilBeaver]

В описании задачи не сказано "зачем"

[khorevaa]

Т.к. текущий формал не редактируемый программо. Мысль какая при установки пакета добавлять автоматически в зависимость разрабатываемого ПО (скрипта или библиотеки)

[nixel2007]

Хм, тот самый opm install -save?
Вообще opm уже содержит сериализованные настройки, зачитанные из Описания пакета... Начинание хорошее, действительно надо подумать

[khorevaa]

Да верно. Мы не иначе смотрим в одно и тоже место и это видимо npm..... Вообще очень не хватает дев зависимостей. Последняя доработка opm это показала. Пришлось 1testrunner 1.4. добавить в зависимость.... но мне это не нравится т.к. данная либа не нужна на клиенте

[khorevaa]

Так же хочу заметить что важен путь git откуда можно скачать сырцы и сразу использовать..... Тоже планирую использовать...

[khorevaa]

Вообще описание покета делать языком onescript не верно т.к. это все таки статичный файл и по идеи там не должно быть "кода", а только описание самого пакета.
Как вариант. было бы просто супер туда добавить разбел "tasks" - наименование таска и исполняемый модуль. Тогда выполнение opm test бы четко знало куда лезть по умочанию для получения исполнителя тестирования. как то так

[nixel2007]

Как вариант. было бы просто супер туда добавить разбел "tasks" - наименование таска и исполняемый модуль. Тогда выполнение opm test бы четко знало куда лезть по умочанию для получения исполнителя тестирования. как то так

tasks как раз есть. в описании пакета это Задачи()

[nixel2007]

и да, я смотрю в npm.

[khorevaa]

tasks как раз есть. в описании пакета это Задачи()

А где почитать какие еще есть функции.. (ткните носом), а то я тут изобретаю велосипед.

[nixel2007]

класс ОписаниеПакета в opm

[EvilBeaver]

А я смотрел в руби, и там описание пакета - это код. И если вы посмотрите на packagedef пакета precommit1c, то увидите, что это полезно.

[nixel2007]

@EvilBeaver соглашусь, полезно. Тот же opm свою версию в манифест подставляет из модуля, а не дублирует в двух местах.

[EvilBeaver]

С другой стороны, у пакета могут быть on-build скрипты генерации этих конфигов. Тут главное понять цель - чего мы хотим добиться переходом на другой формат?