Rime version 3

[not522]

Rimeの設計を大幅に見直す検討をしています。特にアーキテクチャが複雑すぎて機能追加が難しくなっている点を解決したいと思っています。
参照 : icpc-jag/rime-plus#9

（参考）
最近よく使われている競プロツール

• Library Checker Problems
• Online Judge Verify Helper

他の作問支援ツール

• Codeforces polygon
• SOJ
• Spica

以下の方針は個人的に考えているもので、開発陣の総意ではありません。コメントで自由に意見をください。

---

まず、rime-plusでの議論に沿って個人的に考えている解決案を書きます。

開発時とは作問事情が大きく変わっていてますますいろいろな機能を追加する必要がある

Rime+でほぼカバーされているのでは？これ以上特殊なジャッジに対応する必要はなさそう。

メタプログラミングをかなり濫用しているのでアーキテクチャが複雑すぎる

これはその通りでもっとシンプルに書き直した方が良い。とはいえ並列実行をするためにはそれなりに工夫が必要。

Python 2 なので Python 3 への移行が必要

移行済み。

config が JSON とかではなく生 python なのでエディタとか周辺ツールの整備がやりづらい

JSON等に移行しましょう。TOMLも良い感じに見えます。

環境合わせ面倒なのでdockerとかクラウドとかと連携したい

GitHub Actionsで完結するようにすると良い感じになるはず。

静的型くれ

Pythonでも型を書けるようになったので多少はマシな状況になった？

コンパイラを揃える話

GitHub Actionsで緩和されるはず。

リアクティブとか部分点ジャッジ

とりあえずRime+で十分？

配布・非Linux

最近はWSLも出たので現状のままでも大きな問題はないはず。

ビルドシステムの話

makeに任せてしまうというのは並列実行を考えると魅力的ですが、可読性が落ちるのではと懸念しています。

---

上記を踏まえて、以下のような方針を検討しています。

• 言語はPythonのまま
• Rime+を本体に統合
• plugin機能を廃止
• 設定ファイルをJSON等に変更
• 問題文生成機能を追加
• GitHub Actionsを使った標準的な作問ワークフローを作る

言語はPythonのまま

元のコードをそのまま活かせるメリットは大きいと思います。

Rime+を本体に統合
plugin機能を廃止

pipでインストールするようになったので、pluginを追加するより本体に機能追加をしてもらう方がやりやすいと思います。

設定ファイルをJSON等に変更

JSONなら外部ライブラリなしで使えるというメリットはありますが、TOMLの方がコメントも書けるなど便利になる可能性はあります。
外部ライブラリを極力減らすことで、pipインストールを上手くできない人が直接Rimeのソースコードを叩いて実行できるようになるメリットはありましたが、そもそもその機能が知られていない上、他でも（ #69 (comment) ）外部ライブラリを使う話が出ているのであまりこだわる必要はないと思います。

問題文生成機能を追加

Google DocsやGitHubで問題文テンプレートを準備し、サンプルや制約の値などを自動的に挿入する機能を追加したいです。
例えば、library-checker-problemsは同じような形式になっています。
https://github.com/yosupo06/library-checker-problems/blob/master/sample/aplusb/task.md

GitHub Actionsを使った標準的な作問フローを作る

現状のRimeだけでは作問フローが完結せず、他のサービスに依存している面がありました。例えばJAGではPukiWiki・Google Docs・Werckerを使っています。これをRime+GitHubで完結するように設計することで、導入を楽にしたいと思っています。一方、Google Docsなどと連携することでより便利になる可能性もあるので、（pluginではなく）追加のスクリプトなどで対応できるようにしたいと思います。

---

この方針で試験的に書き直しを進めています。現状はpluginを廃止し機能は本体に取り込み、設定ファイルをJSONに書き直している途中です。

https://github.com/not522/rime/tree/v2

[hiroshi-cl]

1つだけコメントしておきます
バージョンは3が良さそうです
https://github.com/icpc-jag/rime/blob/master/setup.py#L5

[not522]

v2がちゃんとリリースされてないので迷ったんですが、v2をスキップしてv3にしますかね。

[nya3jp]

長い間コントリビュートしていない身ですが、とりとめもなく考えていたアイデアを投下します。

事実上 Rime は独立したビルドシステムを提供しています。しかしビルドシステムというのは一般に複雑になりがちで、現状の Rime 内部の複雑性の大部分はここから来ていると思っています。また、Rime が想定している "自然な" ユースケースのみの利用であれば設定ファイル内のコードの記述量は最低限で済みますが、少しでもそこを外れようとすると (例えばユニットテストを書きたい等) プラグインを書く必要が出てきて、プラグインを書くためには Rime 内部の理解が必要になり、ハードルが著しく上がります。

機能拡張をするのが難しいというのはかなり大きな問題だと思っています。今日ではプログラミングコンテストの形式もいろいろあるので Rime がフィットしないケースも多いでしょう。問題文や入出力ファイルを同じリポジトリで管理してデプロイも自動化したいというのはコンテスト運営に関わったことのある全ての人が思うことだと思いますが、そういったことも機能拡張の難しさによって阻害されていると感じます。

なので、もし私が Rime をフルスクラッチでやり直すのであれば、別の既存のビルドシステムのルールセットとして書き直すと思います。

問題はどのビルドシステムを採用するかです。作問者の環境が Windows/Mac/Linux とバラバラなことも多いので、Make のように実行コマンドを直接記述するものよりはある程度抽象度をもったルールを書けるものがよいだろうとは思っています（なお Rime の前身は Makefile + perl で書かれており、とてもメンテナンスできるものではありませんでした）。未だにデファクトスタンダード的なビルドシステムは無いと思っていますが、少なくとも Rime が最初に書かれた当時に比べて選択肢は増えています。

候補として考えていたのはこんなところです:

• Bazel - Battle-tested でオンラインリソースも結構ある。インストールが面倒（要 JVM）、ローカルサーバが重いのもネック。ちなみにおそらくお察しの通りRime の設定ファイルの文法は Bazel のものを意識しています。
• CMake - ポピュラーで実用的。オンラインリソースも多くインストールもパッケージシステムで出来そう。しかし複雑で書き方が複数あり学習コストは高めな気がする。
• Please - Bazel-like だが Go で書かれていてインストールが容易（JVM 不要）、高速に動作する。有名ではなさそう。
• GN - Chromium で使われているビルドシステム。ドキュメントはそれなりにあるがオンラインリソースは厳しい。

元の方向性 (Rime v3) とは結構違いますが、どうでしょう。

[not522]

ビルドシステムを提供することで内部が複雑になってしまっているというのはその通りだと思います。既存のビルドシステムの使用で懸念しているのは以下の2点です。

1. ほぼ書き直しになるので開発コストが大きい
2. ユーザの導入コストが上がるのでは？

1についてはPythonのままで移行出来る方が楽だろうと考えています。将来的に完全な作り直しを目指すにしても、v3で既存コードのリファクタリングがされてある方が開発しやすいと思います。

2についてはビルドシステムをあまり多用したことがないのでよく分かっていないんですが、ユーザの学習コストが高いのではないかと思ってます。ただ、デファクトスタンダードがあるのならば、学習コストを払うのはユーザにとって将来的にメリットになる可能性が大きいので許容できると思います。

拡張性をどの程度持たせておくかは難しいところですが、あまりに柔軟にしようとすると設計が複雑になってしまいますし、大部分のユースケースがカバーされていれば十分ではないかと思います。極端に変わった形式に対してはRimeとは独立したツールを開発した方が楽だろうと思っています。設定ファイルをJSON等に変更することで、別のツールとの組合せもやり易くなるだろうと思います。

現状としては既存コードのリファクタリングを優先するべきかなと思っています。既存のビルドシステムの導入は実際うまくいくのかよく分からないので、やるとしたらコンパクトな叩き台から始めるべきかなと思います。

[nya3jp]

not さんの2点の懸念は妥当だと思います。既存のビルドシステムに Rime のワークフローが馴染むかどうかは実際に試してみないと分からないところもあり、言い出した手前、デモくらいは書いてみようかなぁと思います。

既存コードのリファクタリングは良いことだと思います。プラグインの削除は妥当な方向性だと思いますし、またたとえばコードを複雑にしている元凶の一つであろう task graph は Python 3 の async/await で置き換えられると思います。

[not522]

async/awaitはかなり使いたいんですが、Python2を切り捨てるのはまだ時期尚早に思えます。なので、asyncioもどきを作って将来的（5年後くらい？）な移行を目指すのかなぁと思っています。とはいえ具体的な実装は固まってないので、これもデモくらいから始めるべきですね。