2016-02-08

おはようございます。たぶんこの時間帯は寝ているので、この記事はきっと予約投稿（どうでもいい）。

ここ数日、重い腰をあげて開発したりメンテしたりしているF#系ライブラリの一部でPaketとFAKEを使うようにしたり、最近の書き方に合わせた。

今回対象にしたのは下記のライブラリ。

基本はProjectScaffoldを参考に、各プロジェクトごとに細かい変更をしている。 ProjectScaffoldはパブリックドメインなので遠慮なく参考にしましょう。

細かい嵌りどころ

そもそもディレクトリ構成が全然違うものは合わせるのに時間がかかる
frameworkAssemblyにFSharp.Coreが設定されているライブラリを参照すると、思いもよらないFSharp.Coreの重複参照を招く
- しかもエラー場所がわかりづらい…
- Paketは今のところ回避手段がない
- paket installやpaket updateで毎回この問題にぶつかるため、温かみのある手作業をする必要がある
nuspecでできることがすべてpaket.templateでできるわけではない
- バージョン参照とか現状無理
- とはいえ、nuspecよりもpaket.templateのほうが楽な部分もあるのでどっちもどっち

そこそこ前からF#界隈だとデファクトスタンダードだったこいつを、なんで去年あたりからようやく使い始めたのかというと

いきなりVisual Studio上でビルドしてもちゃんと依存パッケージをダウンロードしてくれるようになった
- 正直これが大きい
- 以前はコマンド叩いてからVS上でビルド…という工程がつらくて使わなかったというのが原因の7割
Paket.VisualStudioができた
- とはいえGUIを一回も使ったことがない…
Visual Studio 2015からnugetからのrestoreを設定してもnuget.exeが入ってこなくなった
- 移行理由の3割
- TravisCIとかを考えるとプロジェクト同梱のほうが楽だなと感じている
  - これは人それぞれだと思う

そういえば最近、groupによって依存パッケージを細かく分離できるようになったようだ。おかげでProjectScaffold内の各種pathも変更されていて、なし崩し的に対応する必要がでたがそこはまた別の話。

とはいえ、NuGetで困らないレベルのライブラリ群は引き続きNuGetでやるつもりである。

DSLが不評だったり若干もっさりするなど、色々言われていたビルドツールFAKEさん。私は消耗したくないのでPowerShellやbashで書けばいいや(それはそれで消耗するのでは、とか突っ込みはなしで)とかずっと思っていましたが、まぁ色々とあるのですよ…。

別言語のビルドツールを使っていたら、抵抗するのがむなしくなった
- npm(+gulp)、sbt、gradle、rebar、mix、etc…
- あれ、どれも大差ないじゃんという気持ちに（もちろん人によって異論はあるだろう）
- 各言語のデファクトスタンダードを使っておけば数年は死なないだろうという結論に至った
  - テスティングフレームワークやビルドツールは他のライブラリよりも入れ替わりサイクルが遅いだろうという甘い考え？
Paketによって敷居が若干下がった？
- NuGet時代はどこにpackage.configを置くか悩んだ
- 悩んだ結果、使わなかった
Gitへのコミットやその他の操作をPowerShellやbashでひたすら頑張ることの限界
- 消耗し始めた
- PowerShellやbashに強いマンではないので…

特に積極的な理由はないという…すみません。

そのうち強い人たちがもっといいものを作ってくれる。

そういう未来を信じるんだ！