Discussion: Could we merge project/packages both MeCab.DotNet and LibNMeCab #32
Comments
|
@kekyo さん こんばんは。 ご提案ありがとうございます。 kekyoさんが、MeCab.DotNetのユーザーを獲得されて、更新を続けていらっしゃること、敬服いたします。 ネットで拝見するに、ご活躍が素晴らしく、大変お忙しい中であること、期待されるお仕事が多くあること、お察しします。 私がこちらで公開したNMeCabの新版は、過去版とのbreaking changeをあまり厭わない方向でやっていました。 私も今は深くは考えきれていないですが、以上のように、基本的にはkekyoさんのご提案に賛同します。 いまヤボ用があって…しばらくは着手できないですが… |
|
@komutan ありがとうございます、私もこの件は急いでいる話でもないので、ゆっくりと進めることが出来れば良いかなと思っています。 具体的な進行が開始されるまでは、このissueを保持しておきたいのですが良いでしょうか？ |
|
@kekyo ありがとうございます！なにもかもありがたく思います。仰るように保存して、またメンションさせてください！ |
|
@kekyo ご無沙汰をしています。 MeCab.DotNetのリポジトリを拝見し、2つのMeCabTaggerクラスのメソッドのシグネチャーを以下に書き出しました。（ポインタ型引数のやDisposeは省略です。） MeCab.DotNet public static MeCabTagger Create() { }
public static MeCabTagger Create(MeCabParam param) { }
public string Parse(string str) { }
public MeCabNode ParseToNode(string str) { }
public IEnumerable<MeCabNode> ParseToNodes(string str) { }
public IEnumerable<MeCabNode> ParseNBestToNode(string str) { }
public string ParseNBest(int n, string str) { }https://github.com/kekyo/MeCab.DotNet/blob/main/MeCab.DotNet/MeCabTagger.cs NMeCab (v0.10.1) public static MeCabTagger Create(string dicDir = null, IEnumerable<string> userDics = null) { }
public MeCabNode[] Parse(string sentence) { }
public Enumerable<MeCabNode[]> ParseNBest(string sentence) { }
public MeCabNode[] ParseSoftWakachi(string sentence, float theta = MeCabParam.DefaltTheta) { }
public MeCabLattice<MeCabNode> ParseToLattice(string sentence, MeCabParam param) { }https://github.com/komutan/NMeCab/blob/master/src/LibNMeCab/MeCabTagger.cs MeCab.DotNet と NMeCab最新版 を単純に取り替えて使う場合には
といった差異がでてきます。 @kekyoさんに、ご検討いただきたいのですが、MeCab.DotNetのAPIはやはり維持しますでしょうか。 以下のようなものを私では考えています。
このコードをMeCab.DotNetにPRで送るのがよいでしょうか。 （後々、まとめて維持することを考えると「リポジトリの一本化」という案もでますが、、そうするとドキュメント等がユーザーから分かりにくくなりそうですし、変更履歴も消えてしまうので、やはりそれはなさそうですね） ご検討・ご意見を頂きたいと思いました。よろしくお願いします。 |
|
@komutan なるほど、案について理解しました。 現状のMeCab.DotNet側のシグネチャを、NMeCabベースの実装で再現が可能ということであれば、明らかに不要となりそうでも、一旦両者のインターフェイスを出来るだけ再現するのが良いと思います（一般的なリファクタリングの原則に従って）。 例えば、Parseの戻り値がNMeCabでリッチな方向に変更されているのはそういった理由があると思いますので、最終的にはMeCab.DotNetのstringを返すバージョンは廃止するように寄せたほうが良いと思っています。 戻り値の型だけが異なるオーバーロードは許されませんが、MeCab.DotNetとNMeCabでは名前空間が異なるので、案の方法で寄せるので良いと思います。部分解析についてもOKです。例外で検出できることと、アナウンスすれば良いでしょう。 （部分解析が必要なユーザーは、最終版を使い続ける選択肢を残せます） リポジトリの一本化ですが、
とあると思います。このうち3はそもそもこの作業をやる意味がなさそうなので無いと思っています（ずっと両者を維持し続けるという意味です）が、どうでしょうか？ 1や2の場合は、organizationを立ててそちらにリポジトリを移設し、しかる後にどちらかをアーカイブして片方に誘導する、ということにすれば、片方の履歴は継続され、片方はアーカイブで残るので良いと思います。 私的には、私の方の履歴はほぼ移植作業（NuGetのパッケージ作るところとかあったかもしれない）なので、実質的には参照さえできればアーカイブで問題ないかなと思っています（アーカイブでも参照したい人がいるかどうか疑わしいですが :) NMeCabの履歴を残す場合の案（NMeCabリポジトリを使う）:
MeCab.DotNetの履歴を残す場合の案（MeCab.DotNetリポジトリを使う）:
リポジトリのorganizationへの移動は、URLが自動的にリダイレクトされるので、今まさに参照している人への影響は少ないと思います（GitHubはローカルのURLの修正を推奨しているので、アナウンスは必要でしょう） 最終的なリポジトリ名を何にするか、については、変更した場合、そのタイミングがorganizationへの移動前後によって、リダイレクトがちゃんと機能するかどうかはわかっていません（一応試した方が良いかも...） なお、第三の案として、NMeCabの履歴を残しつつMeCab.DotNet側のコードベースで作業する場合（あるいはその逆）は、その時点のソースコード一式を無理やり全入れ替えしてcommitを作るという方法も無くはないです。例えば: # NMeCabのcloneで
git clean -xfd
# 現在のファイルを全部削除 (.git/ 以外)
rm -rf * .gitignore
# MeCab.DotNetのコードをコピー
cp -R ../MeCab.DotNet/* ../MeCab.DotNet/.gitignore
# コミットすると、NMeCabの履歴ベースでMeCab.DotNetのコードになる（強引）
git commit -m "Imported from MeCab.DotNet"
# 以後、NMeCabのコードを手動で取り込む...
# 取り込みが終わったらSquashすれば、差分が多少マシになるかもしれないです。 |
|
@kekyo APIについてもリポジトリに関しても、詳しく複数案いただいており、ありがとうございます。 この週末に融合したパッケージのコーディングの時間が取れると思います。 |
|
@komutan 了解しました、ではNMeCabのリポジトリで作業を進行して、リポジトリの以降は次の段階でやりましょう。 開発速度については全く気にしていませんので（GitHubでやる上にOSSの活動なので、非同期進行で一向に構いませんよ :) 無理のない範囲でやって下さい。 とりあえず最初のそちらの変更分が出来たら、こちらでもそれを評価してみます。ブランチ切った時点でPR立てて、実際の修正はその上でやるのが良いかと思います。 |
こんにちは、komutanさんの方の更新が続いていて良かったです。
私の方のMeCab.DotNetの方も、主に環境面でのissueについて更新を行っていますが、komutanさんの方の変更に追従できていなくて、どうしようかと思っています。いっそのこと、こちらのプロジェクトとの統合を考えてみたらどうだろうかと考え、まずは意見を聞きたくてissueを立てました。
MeCab.DotNetは、そもそも私がとあるイベント向けに.NET Core環境で使いたくて移植した、という経緯があったのですが、公開後、海外の方にも使われていることが分かり、（主に開発環境面での更新、例えば.NET Coreの新しいバージョンが出たなどで困らないよう）半ば義務感で更新を続けている状況です。
（イベントについては長文ですが私のブログにまとめています）
いくつか私的なプロジェクト（主に非公開）で使用しているのですが、形態素解析自体の知識があるわけではないので、あくまで前述の範囲での更新となってしまっているのが気になっています。恐らくは、コア部分の機能改善についてはkomutanさんの方が進んでいると思いますので、例えば現在のように開発環境面での更新や機能強化という点で協力できる部分があると思います。
そこで、2つのプロジェクトの統合を考えたのですが、別々にforkしていた方が開発がやりやすいとか何か理由があるようでしたら、それはそれでも一向に構いませんので、そのように言って頂ければと思います。
統合した場合の問題点について、まだあまり深く考えていませんが:
とりあえず、今思いついていることは書き出してみましたが、何か意見があればお願いします。
The text was updated successfully, but these errors were encountered: