Vimプラグインのメタデータを集約するリポジトリを作ろうという話
@tyru @Linda_pp 別に日本人だけで頑張る必要はないので、vim-jpとは独立したOrganization作るのが良いのではないでしょうか。やるなら協力しますよ。
2016-01-04 09:06:10@tyru @Linda_pp さいきんだと、vimawesome.comが将来有望だったのですが、メンテナンスされおらず新しいメンテナンスを探してるところです
2016-01-04 09:07:23@tyru @Linda_pp このプロジェクトが成功するかはプラグインマネージャ製作者やプラグイン作者をどれだけ巻き込めるかにかかっています。最終的にはvimリポジトリに突っ込んで公式化するのを目標にするべきでしょう。だからこそ、最初の設計は重要になります。
2016-01-04 09:09:46@tyru @Linda_pp vimの場合、標準パッケージマネージャがないということよりもプラグインのメタデータリポジトリがないことのほうが問題になっていました。vimawesomeはユーザーインタフェースを改善しましたがそこで止まってしまっています
2016-01-04 09:11:46@tyru @Linda_pp perl6のecosystemが参考になるかも github.com/perl6/ecosystem 皆がMETA.listにprを送ってモジュール側は依存情報を含んだMETA6.jsonを公開する感じ。 github.com/mattn/p6-Growl…
2016-01-04 10:24:47@ShougoMatsu @Linda_pp ありがとうございます!今vim-vivaciousのmemberにinviteしました。github.com/vim-vivacious metainfoってリポジトリ作ってそこにメタ情報集めるつもりです。作ったらよろしくお願いします。
2016-01-04 20:46:04@Linda_pp あ、すみません。mention行ってしまいましたがりんだんさんには送ってないです。もちろん協力してくれるならぜひ送りますが!
2016-01-04 20:48:12@mattn_jp @Linda_pp ありがとうございます。ただこれだとリポジトリにMETA6.jsonを含める必要があるんですね。今もうVimプラグインのリポジトリは沢山あるので、できれば加えない方向で行きたいです…!
2016-01-04 20:50:32@mattn_jp @Linda_pp りんだんさんのcrates.io のリポジトリの例だと一つのリポジトリに全部メタ情報がまとまってて、こちらで勝手に追加とかも出来るのでそれがいいかなと。
2016-01-04 20:53:26@tyru @Linda_pp ありがとうございます。当面の課題としては、データ構造の決定とプラグイン名のコンフリクト解決になると思います。データ構造は一度決めると変えられないので。他のリポジトリを参考にした方が良いかもしれません。
2016-01-04 20:58:42@tyru @Linda_pp プラグイン名が被る問題をどう処理するかという問題があります。forkしたリポジトリや、意図せずに被ってしまったもの。vim.orgでも名前は重複してしまってますが、あちらは番号で管理してますね。
2016-01-04 21:00:49@ShougoMatsu @Linda_pp メタ情報のデータ構造はLTSVを予定してます。ただ(gh-pagesで)jekyllでJSONとかに変換して返せそうな気もしますが、詳しくないので分かりません。 ここらへん @mattn_jp さんとか詳しそうなので聞きたいです。
2016-01-04 21:01:45@ShougoMatsu @Linda_pp そうですねぇ。リポジトリ内でのメタ情報ファイルの置き場所を /<user>/<reponame> とかにした方が良さそうですね。もちろんユーザはGitHubの。
2016-01-04 21:03:56@tyru @Linda_pp @mattn_jp vim部屋やissuesで相談しても良いかも。私はLTSVでも良いですが、コメント書けない問題はどうしますか? LTSVはあまり人が書くのには向いてないような。そこはjsonも微妙ですけど。
2016-01-04 21:04:02@tyru @Linda_pp それは一つの手ですね。プルリクエストを処理するときにチェックが必要になりますけど。うまくやれば、vim.orgのプラグインを管理することも可能になります。
2016-01-04 21:05:30@tyru @Linda_pp あと、メタデータは一つのディレクトリにまとめるとすごく肥大化するのが避けられないので、何らかの構造化はいりますね。
2016-01-04 21:06:24@ShougoMatsu @Linda_pp @mattn_jp LTSVにしたのはパースするのにeval()したくないのと、パースが楽だからです。JSONもコメントは書けないですね。(続)
2016-01-04 21:08:30@ShougoMatsu @Linda_pp @mattn_jp 自分はコメントは想定してなくて、Rustの crates.io のようなリポジトリのメタ情報ファイルを想定してます。 github.com/rust-lang/crat…
2016-01-04 21:08:47@tyru @Linda_pp @mattn_jp なるほど。確かにevalはやりたくないですね。ただ、LTSVは一行が長くなるという問題があるのではないでしょうか。複数行に分けて書くのなら、その問題はないですが。
2016-01-04 21:10:58@ShougoMatsu @tyru メタデータは現状,依存関係解決のためにあるはずなので,依存解決が必要なプラグインのみオプションで使えるものにすべきだと思います.あと,おそらく issue で議論したほうが良いです.ツイッター上のやり取りは流れてしまうので…
2016-01-04 21:11:36@Linda_pp @tyru わたしは依存関係だけでなく、メタデータをプラグイン検索のために使えて良いと思います。
2016-01-04 21:14:06@ShougoMatsu @Linda_pp @mattn_jp うーん、LTSVのフォーマットの仕様を変える事はあまりしたくないです。オレオレパーサーを安易に作るのは良くないかと。>複数行
2016-01-04 21:14:10@tyru @Linda_pp @mattn_jp フォーマットは変えず、LTSVのための支援プラグインがあると良いのかもしれませんね。
2016-01-04 21:15:27@ShougoMatsu @tyru package.json みたいなのをイメージされてると思うんですが,あれは npm だからできるのであって,一個人がつくったパッケージマネージャにできることではないと思います.小さく始めるのが良いんじゃないかと…
2016-01-04 21:16:56