#というわけで、このようなcabalにまつわる話が
##にまとめてみてあるので、是非ツッコミをいただきたくーーーーー。よろしくお願いします。
#あ、ツッコミは @master_q にmentionをなげてくれた方がうれしいですーー
#cabal install fooしたいだけの人が居て、そこで最新の依存ライブラリbarがダウンロード&インストールされて、さて本命のプログラムfooがビルドされる時にコンパイルエラーになるってことですか？
#そうですね。 < 本命のプログラムfooがビルドされる時にコンパイルエラー
#でもそれは不幸な場合です。願わくば大抵の場合は既存APIを変更するのはマレだと思いたいです。
#仮にfooが依存しているライブラリのセイでfooがエラーになったとしても、それはfooがライブラリへ追従してないないこと*も*問題ですよね。
#こういうのが放置されるとHackage群全体の整合がだんだんくずれていってしまうと思います。
#「Hackageは壮大な実験場である」という見解はあるとは思いますが。。。一人のエンドユーザとしては全体整合が数ヶ月も崩れたままってのはツライです。。。
#Haskell特有の話ではないですが、「既存APIを変更するのはマレ」「全体整合」は経験的に実現不可能だと思います。定性的ですが、規模が大きくなり開発の並列度が上がれば上がるほど全体の整合を保つのは難しくなり、また新しいアイディアや抽象が得られれば得られるだけ既存APIを直したくなります。つまり上の二つの目標はソフトウェアの進化の方向とは本質的に相容れない気がするんですよね。じゃあどうすればいいかっていうと特効薬は私も持ってないのですが。
#はい。GHC や Haskell Platform 限定ではなく、Cabal でパッケージを作る人達が守るべき取り決めですね。 > これってパッケージ群についても言えると思っていいでしょうか？
#ぼくが気にしているのは依存しているHackageの上限を設定できてしまうことによって、Hackage作者の全体整合に対するモチベーションが下がってしまうという懸念です。
#全体整合が綺麗にととのっていることは無理で、それに近い方向で努力できるような環境になっていた方が良いのではないか？という意見です
#個人的な意見です。
#はい。なのでパッケージのバージョン番号に変わる解決策として、モジュールシステムを拡張し、パッケージ記述言語を取り入れようという試みを現在行っていますね。 http://t.co/pk0BdZXg #パッケージ記述言語は前から聞いていたのですが、まだよく理解できていません。せっかくなので見てみます...λ
#まだ問題点を整理している段階で、具体的なデザインに関する情報はまだ出てきていませんが。
#.｡oO(辛うじて MixML を参考にするという情報が出ているぐらいです。 http://t.co/EqLhNEla ) #コンパイル時に検出できるAPI変更なら、リポジトリの方で継続的にコンパイルかけて、パッケージAがアップデートされたらBがエラーになった、ってところでBに互換性情報を付け加えるとかできないんかな。Bの作者がBが使うAの上限を申告するんじゃなくて。
#それがなんかyesodを使ってたらコンパイルは正常終了したのだけれど動作が変で、.cabalと.ghcを消してからcabal installしたら動作正常になった経験が。。。
#パッケージ数が増えるとスケールしないか。むしろボランティアユーザが自分のとこにインストールした時に出たエラー情報を自動でフィードバックするとか。
#あれは夢を見ていたのでしょうか。。。
#いちおうこのような作業をディストリビュータがやる、というのは別に反対ではありません。今回の筑波の発表では「cabalで生で入れるよりもDebianやらGentooやらでパッケージとして扱った方がいい場面があるよ」というモチベーションを説明したかったのでまとめてみただけすた。
#ghcがコンパイルするときに、そのモジュールがどんなAPIを公開しているかは追跡できてるんだし、型が全部分かってるんだから、API(の集合)が変わったかどうか分かるし、それからハッシュ値なり生成できるんじゃないかと思うんだけどな。
#ライブラリ作者は例えば設計が古くなっちゃったり、別のことに取り組んだりして放置してしまうことはありうると思うので、それが原因でビルドできないのはいやだなぁ。
#でもハッシュ値だと一致するかどうかは調べられるけど、上位互換かどうかは面倒なんじゃ?
#上位互換というとどういうものを考えてますか？
#あ、一応ハッシュだけではだめで、HackageDBにアップされた時にシリアル番号を取る必要はあるって思ってます。
#同じAPIだった時にどっちが後のバージョンか分かる必要があるので。
#そういう意味ではない？
#よくよく考えたらこのバージョン付番のポリシーってAPI追加した場合にはマイナーでいいよ、だけど追加したAPIが利用者側で同じ名前同じ型で自作されてたりする可能性があるから多少なり影響するんじゃないのかとか思った。
#ビルドできなくてhidingしないと通らないとかありそうな気がする。
#今のポリシーだと大抵ライブラリ作成者はマイナーバージョンが変わる分にはよしにしてると思うんですけど、つまり foo >= 3.1 && < 3.2みたいに。
#マイナーな更新に伴ってAPIが追加されたり拡張されたけど、古いバージョンに依存してたライブラリはそのまま使い続けられる、ってケースは多いと思うのですが、ハッシュ値で管理してる時にそういうのはどうするのかなって思って。そういうんじゃなくて、バージョンを完全に同定するためにハッシュ値を使うってことなのかな
#あ、そうです。cabalの版番号のポリシーでも確かにAPIの追加などはマイナーバージョンアップの位置づけっぽいですけど、ハッシュ値使ったらメジャー扱いですね。
#一応 GHC に、パッケージの（API ではなく）ABI の互換性を確かめるためのハッシュ値を算出する機能はありますよ。 http://t.co/iX2mHrhF http://t.co/rzqEPCyk http://t.co/3UsdKjai #ただし、GHC で利用されているだけで、cabal でパッケージ間の問題を解決するのには活用されていませんが。
#それはshiroさんが言うようなケースを考慮してのことでしょうかね。
#APIの追加も拡張もされないバージョンアップっていうと純粋なbug fixとか、かなり限られそうな気がするんだけれど、文化が違うのかなあ。
#あーでも理屈から言ったら、モジュールをqualifyせず、明示的な名前の列挙もせずにインポートしてる場合、そのモジュールにAPIが追加されることで名前の衝突が起き得るから、他のライブラリを壊してしまう可能性はあるわけか。
#むしろ、モジュールやパッケージの必要でない再コンパイル/ビルドをできるだけ防ぎたいというのが、この機能のモチベーションですね。詳しくは Design constraints を見てください。 http://t.co/hCJRZFN3 #なるほど。どっちかというとmakeがやってるようなビルド依存関係の解析をもうちょっとちゃんとやろうって話、と理解すればいいのかな。それなら厳密な一致比較が必要なのはわかります。cutseaさんが問題にしてるのはもうちょい広い話で、分散開発されてるパッケージ間で動作するバージョンの組み合わせをどう追跡するかって話だと理解してました。
haskell-ja > Archives > 2011/10/14