Rime version 3 about rime

[not522]

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

[hiroshi-cl]

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

[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年後くらい？）な移行を目指すのかなぁと思っています。とはいえ具体的な実装は固まってないので、これもデモくらいから始めるべきですね。