![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
あまり詳しくないから的外れかもしれないけど、 Haskellのdependency hellの要因の一つとして、sbtやmavenみたいに細かくサブプロジェクトに分ける機能(もしくは文化)がcabalに存在しないから、依存増えすぎる傾向がある気がするんだけどそういうことではない?
2013-12-13 22:48:23![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
.@xuwei_k 細かくサブプロジェクトに分けると、dep hell が無くなる理由はなんですか? それと、cabal はすでに sandbox をサポートしているので、dep hell が問題になることは、もはや少ないと思います。
2013-12-15 08:47:07![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
@kazu_yamamoto あるプロジェクトAが、BとCのライブラリに依存してるとします。 それで、Aにおいて、Bは全体的に使ってるけど、Cは少ししか使ってないので、その場合Aを「Bのみに依存する部分」と「BとC両立に依存する部分」に分けることが可能だと思うんですが(続く
2013-12-15 08:54:22![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
@kazu_yamamoto で、ビルドツール自体に手軽にそのようにサブプロジェクトに分ける機能がないと、そうやってわける方向性にならないのかな?と。もし現状そのようにAを分割する場合、リポジトリ分けることになる? → それは少し面倒なのでやらない。となるという想像なのですが
2013-12-15 08:57:04![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
@xuwei_k @kazu_yamamoto 分ける前は(A, B), (A, C)のバージョンの組について考えていたのが、(A', B), (A'', B), (A'', C), (A', A''), (B(A'), B(A'')) について考えることになるのでは
2013-12-15 09:07:43![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
@omasanori なるほど、やはりそうするとデメリットもでてきますかね。Haskellのそのあたりの理解が曖昧なんですが、だとしても分けた場合「Cに依存していないA(Bのみに依存してるA)」が欲しいユーザーにとっては嬉しいと思うんですが、他のデメリットが上回りますかね?
2013-12-15 09:17:58![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
@xuwei_k A' <- B とA'' <- (A', C) なら考える組み合わせは (A', B), (A', A''), (A'', C) と1つ増えるだけで済みますし、A'とA''を同一のチームが管理しているのであれば (A', A'') のコントロールは難しくないので
2013-12-15 09:23:33![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
@xuwei_k うまく依存グラフを組み立てれば分けることによるデメリットは十分小さくなると思います。ただ、Cabalのバッケージは分割をサボっているという印象が私にはないですね。(依存関係の大きさではなく機能で分割するために依存関係が巨大なパッケージがある?)
2013-12-15 09:27:02![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
.@xuwei_k Haskell はライブラリを細かく分ける文化なので、そこは問題ではないです。むしろ、細かく分けるからこそ、dep hell が起こります。
2013-12-15 12:18:59