manifest_assets/base_info.jsonのような、エンジンの情報を入れるファイルの仕様を決める

[sevenc-nanashi]

内容

タイトル通り。

Pros 良くなる点

カスタムエンジンや、UIなどが作りやすくなる

Cons 悪くなる点

実現方法

VOICEVOX/voicevox#840 に少し追加して。

// 第二版
interface EngineInfo {
  // フォーマットのバージョン
  manifest_version: number

  // 名前
  name: string

  // エンジンごとのUUID4
  uuid: string

  // ホームページのURL
  url?: string

  // バージョン
  version: string

  // 起動コマンド（Windowsなら`cmd /c`、Macとかだと`/bin/sh -c`で実行する
  // 他のサーバーで起動しているなら省略
  command?: string

  // HTTPサーバーのアドレス
  host: string

  // ドキュメントのファイル名
  documents: {
    dependency_licenses: string
    terms_of_service: string
    update_infos: string
  }

  // アイコン（base64？ファイルパス？）
  icon: string

  // 開発者の情報
  developer: {
    // 名前
    name: string

    // URL
    url?: string
  }
}

関連

• エンジンのプラグイン化（複数のエンジンを同時に見れるようにする） voicevox_project#2
• カスタムエンジンの構成について voicevox#840

その他

shirowanisanさんあたりから話を聞いてみたいです。

[Hiroshiba]

issue作成ありがとうございます！
ホームページとか確かにあると便利だなと感じました！

とりあえず、いろいろ視点を足してみました。

scheme_version

既存のに合わせるとmanifest_versionですかね

id

一意性を考えるのが面倒なので、UUID4が良いかなーとか思ってます。
明示的にするためにkey名もuuidにしたいかも。

command

コマンドなのか実行ファイルなのか決めちゃいたいかもです。
引数を指定可能にするならコマンドのが正しそうですが、ぐちゃぐちゃになるので一旦実行ファイルのが通りが良いかも？
となるとkey名も変えたほうが良いかも。executable･･･？ 🤔

host

localhostか127.0.0.1で固定だろうからなくても良いかも。
あ、もしくはクラウド版を想定されてたりしますか 👀

documents

用意すべきものがいくつかあるので、それは定義済みにしちゃいますか。

• dependency_licenses
• icon
• terms_of_service
• update_infos

がありそう。（iconはrootでも良いかも）

developer

開発者情報載せるの良いですね！！！

[sevenc-nanashi]

scheme_version：manifest_version？

そっちの方が良いですね。

id：UUID

例えば、vvprojファイルを他の人と共有する場合、エンジン sevenc7c.my-awesome-engine が不足しています。みたいに表示できたらマシになるかなと思いました。（vvproj内にurlと名前を埋め込んじゃってもいいかも？）

host：クラウド版の想定

そうですねー。どこかで外部サーバーでエンジンをホストする話が出ていたような気がしたので。

command：executable？

dockerで動かすエンジンとかだとcommandとかの方が良いかなと思ってコマンドにしてます。

documents：事前定義

確かに、決めておくとアイコンとかもつけやすそうですね。
それとは別に、エンジン毎のドキュメントもあっても良いと思います。

documents：icon

これはrootでも良さそうですね。

---

最初のメッセージを更新しました。

[Hiroshiba]

id：UUID
例えば、vvprojファイルを他の人と共有する場合、エンジン sevenc7c.my-awesome-engine が不足しています。みたいに表示できたらマシになるかなと思いました。（vvproj内にurlと名前を埋め込んじゃってもいいかも？）

なるほどです！
難しいところですが、名前をなんとかして埋め込むのが良いのかなと思いました。

host：クラウド版の想定
そうですねー。どこかで外部サーバーでエンジンをホストする話が出ていたような気がしたので。

なるほどです。
外部サーバーにアクセスしたいときはありそうですが、そのためにbase_info.jsonファイルをローカルに作るよりかは、UI上で設定できる方が便利そうな気がしました。
となると、hostはなくても良いかも？

command：executable？
dockerで動かすエンジンとかだとcommandとかの方が良いかなと思ってコマンドにしてます。

なるほどです！
例えばエンジンをGPUモードで起動する場合、引数に「--use_gpu」を指定するのですが、この引数の位置とかも指定可能にできる必要がありそうな気がしました。
が、拡張性を考えるとcommandの方が良さそうだと思います！

documents：事前定義
確かに、決めておくとアイコンとかもつけやすそうですね。
それとは別に、エンジン毎のドキュメントもあっても良いと思います。

ここでいうドキュメントは、使い方などを想定していますか 👀
（任意のkeyを設定できるようになっている意図を知りたい感じです！）

[sevenc-nanashi]

例えばエンジンをGPUモードで起動する場合、引数に「--use_gpu」を指定するのですが、

確かに。うーん、

{
  // ...
  "command": "run.exe {use_gpu?--use_gpu:}",
  "settings": {
    "use_gpu": {
      "type": "boolean",
      "description": "GPUモードにするかどうか"
    }
  }
}

こんな感じにsettingsをつけて、引数をいじれるようにする…？

（任意のkeyを設定できるようになっている意図を知りたい感じです！）

最初は、

{
  "使い方": "docs/tutorial.md",
  "利用規約": "docs/tos.md",
  "開発者達": "docs/developers.md",
  "サポート": "docs/support.md",
}

のように、

この画面の左をキーとしてやる想定でした。

[sevenc-nanashi]

あ、言い忘れてましたが、これはAPIじゃなく、エンジンと一緒にjsonファイルとして配布する感じでした（ブラウザ拡張のmanifest.jsonみたいな）

[Hiroshiba]

こんな感じにsettingsをつけて、引数をいじれるようにする…？

なるほどです！settingsだと何を示すのか少しややこしいかもです。dockerとかに倣うと、argsとか…？
ただ、そこまでの汎用性が必要なエンジンは今のところ無さそうなのと、使う側が個別対応する必要が出てきて大変なので、優先度は高くないかもと感じました！

この画面の左をキーとしてやる想定でした

なるほどです！
こちらである程度規定し、あとは自由に設定できるといろいろ使いかもと思いました！
順番も大事だったらlistのが良いかも…？

一緒に配布

良いと思います！
実際今もbase info.jsonは配布ファイル内に含まれてるはずです。

[sevenc-nanashi]

それか、エンジン側で--use_gpuを無視して貰う、と言う手も。
（もういっそUSE_GPU環境変数で制御する？）

[sevenc-nanashi]

ユーザーで変更するポートもPORT環境変数あたりで渡したら楽になりそう

[Hiroshiba]

なるほどです！
引数か環境変数かはいったんどちらでも良いかなと思います。
といのも、VOICEVOXはまだベータ版なのでいろいろ試すことができるステータスなので、とりあえず動く形に最速で持っていきたいんですよね。まず動いてるところを見たい･･･！！！

「動くのに必須なもの」「あると捗るもの」「まあなくても良いもの」に分けて、それぞれをmust/want/canにし、箇条書きにしてまとめるとかはどうでしょう 👀

[sevenc-nanashi]

「動くのに必須なもの」「あると捗るもの」「まあなくても良いもの」に分けて、それぞれをmust/want/canにし、箇条書きにしてまとめるとかはどうでしょう 👀

というと？

[Hiroshiba]

ちょっと後ろのmust/want/canが余計でした。。こんな感じを想像しています！

必須

• command
• id

あると捗るもの（なくても動くけど、あると楽になったりするもの。↑よりは優先度が低い。）

• developer

まあなくても良いもの（↑以外。とりあえずメモして、実装の優先度は下げる）

• executable
• args
• documents

[sevenc-nanashi]

なるほど。
最悪uuid、command、portだけで動くような気がします

[Hiroshiba]

同感です･･･！！その中でissueのとこに無いのはportだけかな。

なんとなくだけど、優先度はこんな感じでどうでしょうか。

must

• uuid: string
• command?: string
• port: int

want

• version: string
• name: string
• documents: {}
• url?: string

can

• host: string
• icon: string
• developer: {}

[sevenc-nanashi]

良さそうです！

[Hiroshiba]

ありがとうございます！

このissueを元に実装するissueを作れば、このissueは解決にしてよさそうな気がします。
そこもお任せしちゃっても良いですか…？👀
（なんなら実装までお任せできると心強いです！！）（実装がマージされるとソフトの貢献者一覧に追加されます）

[sevenc-nanashi]

このissueを元に実装するissueを作れば、このissueは解決にしてよさそうな気がします。

実装する、というと、Voicevoxの方ですか？

[Hiroshiba]

まずエンジン側のbase_info.jsonを修正して、あとはVOICEVOXの方になるかなと思います！！

そういえばbase_info.jsonは、もともとは別の情報も足すからbase_infoだったのですが、もう足さない感じになっているのでmanifest.jsonの方がわかりやすいかも･･･？