Project

General

Profile

=begin
= 標準添付ライブラリを gem にする計画

まだ [ruby-core:32156] の要約 (しかも不完全) だけです。

== 用語

: stdlib
現在の標準添付ライブラリのこと
: stdlib gem
gem 化された標準添付ライブラリのこと。
: Ruby distribution
Ruby のリリースパッケージ。通常 tarball 。
: security release
security issue が判明した際に Ruby distribution をリリースすること。

== アプローチのバリエーション

  • V-A) stdlib gem の開発をどこで行うか

    • V-A-1) Ruby の SVN リポジトリで
    • V-A-2) 別のリポジトリ (github 等) で
    • V-A-3) 別のリポジトリをメインに使い、Ruby の SVN リポジトリでミラー
    • 現在は V-A-3 (rake や rubygems のスタイル)

  • V-B) stdlib gem の配布形式をどうするか

    • V-B-1) gem を Ruby distribution に含める
      • make install 時に "gem install .../foo.gem" を実行する
    • V-B-2) gem のソースを Ruby distribution に含める
      • make install 時に通常のライブラリだけでなく gemspec ファイルもインストールする
      • V-A-1 か V-A-3 の場合だけ可能
    • V-B-3) gem を一切 Ruby distribution に含めない
      • make install 時に "gem install foo" を呼んでネットワークインストールする
    • 現在は V-B-2

  • V-C) どの stdlib を gem 化するか

    • 前提: rubygems を動かすために必要な stdlib は gem 化できない
    • V-C-1) rubygems を動かすために必要ないもの全て gem にする
      • rubygems に optionally に必要とされるものはどうするか？ (例 openssl)
    • V-C-2) make test-all に必要ないもの全て gem にする
      • 例: webrick は rubygems に必要な net/http のテストで必要なので消せない

  • V-D) stdlib gem を増やすか

    • 候補: Nokogiri, RBTree, NArray

  • V-E) 移行段階 [ruby-core:32397]

== 利点

  • P-A) stdlib gem のリリースサイクルを Ruby distribution から分離できる [ruby-core:32195]

    • P-A-1) stdlib gem の rapid release が可能になる
      • ユーザがバグを monkey patching で対策しなくてすむ
      • [Objection] Ruby のパッチリリースで更新すればよい
    • P-A-2) stdlib gem 開発者が好きな VCS を使える (V-A-2 か V-A-3 の場合)
    • P-A-3) stdlib gem のバグで security release する手間が要らなくなる
      • [Objection] C-F を見よ
    • P-A-4) stdlib gem 開発者がユーザからの feedback を得やすくなる [ruby-core:32293]
      • Ruby distribution のリリースの際に gem をテストする必要がない (?)
      • [Objection] 説得力なし

  • P-B) stdlib gem を gem コマンドで操作できる

    • P-B-1) security update の際、"gem update" だけで済んで簡単
    • P-B-2) stdlib gem の取捨選択ができる [ruby-core:32423]
      • こだわる人は、使わない標準ライブラリを消して必要最小限のセットアップにできる

== 欠点

  • C-A) bug tracking が複雑になる (V-A-2 か V-A-3 の場合)

    • C-A-1) どこにバグ報告すればいいかユーザにわかりにくい
      • stdlib gem 開発元か、ruby redmine か
    • C-A-2) security issue はむやみにたらい回しできない [ruby-core:32316]
      • rubygems.org のような open collaboration tool はダメ
      • communication cost が高くなる
      • [Objection] どのみち upstream には報告しなければならない
        • 現状 (V-A-3) でも変わらないので、V-A-2 にしない理由にはならない
    • C-A-3) バグ情報が分散してしまう

  • C-B) リリース作業が大変になる (V-A-2 の場合)

    • C-B-1) stdlib gem 開発者が忙しくてバグを直してくれない
      • リリース直前や security issue には迅速な対応を要する
      • V-A-1 か V-A-3 であれば、任意のコミッタが対処できる
    • C-B-2) 従来の security release に加え、gem をリリースする作業が増える

  • C-C) V-A-3 はバージョンが混乱するから避けるべき [ruby-core:32300]

    • stdlib gem 開発者がアクティブであれば問題ないのだが
    • upstream に報告したのに直してくれない場合 [Yusuke->Eric] [unak->rake]

  • C-D) Gem developer の開発スタイルを変えなければならない (特に V-A-1 の場合)

    • C-D-1) Ruby のリリースサイクルに引きずられる
      • [Objection] V-A-1 であっても svn の lib/ から gem を別リリースすればいい [ruby-core:32195]
    • C-D-2) subversion を使いたくない、github が使えない

  • C-E) stdlib gems をむやみにいじれるのは混乱を招く [ruby-core:32173]

  • C-F) security release はどのみち必要 [ruby-core:32275]

    • (これは Gem 化の欠点というより P-A-3 の否定です)
    • C-F-1) インターネット接続がない環境で Ruby 使ってる人がいる
      • [Objection] どうせパッケージ持ってこないといけないんだから関係ない [ruby-core:32293]
    • C-F-2) gem の occasional update をできる気がしない (?)
    • C-F-3) そもそも、core team はリリース作業自体を苦にしていない
      • よって P-A-3 は手間ですらない
      • メンテされていないライブラリを修正する作業が圧倒的に苦
        =end