sbt での Selective ファンクター

Selective ファンクターは inspect コマンドを犠牲にせずにタスクの条件的実行を可能とする仕組みを提供する。

sbt では、Selective 合成は Def.taskIf マクロを使って表すことができる:

Def.taskIf {
  if (Boolean) something1
  else something2
}

sbt への pull req は sbt/sbt#5558だ。

sbt で約束 (promise) を守る

in

build.sbt は、自動的な並列処理を行うタスク・グラフを定義するための DSL だ。タスク同士のメッセージ・パッシングは something.value マクロで表され、これは Applicative 合成 (task1, task2) mapN { case (t1, t2) => .... } をエンコードする。

長く走っている task1 があるとき、途中で task2 と通信できる仕組みがあればいいと思っていた。

promise

sbt でのコンパイルキャッシュ

in

コンパイルキャッシュ (もしくはリモートキャッシュ) という概念はしばらくあったものだが、それを実際にセットアップするのは簡単ではなかった。「関数としてのビルド」機能を基礎的なツールチェインである Zinc や sbt に仕込むことで Scala コミュニティー全体がビルドの高速化の恩恵が得られると思っている。

オープンソースのプロジェクトでも Travis CI が Bintray にキャッシュをプッシュすれば、コントリビューターは最新のビルドからコンパイルをレジュームということができるかもしれない。

sbt の変更の pull req は sbt/sbt#5534 で、Zinc 側の仮想ファイル化は sbt/zinc#712 だ。

Zinc 1.4.0-M1

Zinc 1.4.0-M1 をリリースした。これはベータ版であって将来の 1.4.x との互換性は保証されないことに注意してほしい。ただ、1.3.x と比較的近いコミットを選んだので実用性は高いはずだ。

並列クロスビルド、パート3

in

sbt-projectmatrix 0.4.0 は結構いい線いっていたが、実際に使ってみると不便な点があった。まずは % 構文が無いことだ。

サブプロジェクト間で Test コンフィギュレーションからだけ依存したり、Compile 同士、Test 同士で依存するというのは良くあることだ。0.5.0 は % を追加してこれを可能とする。

lazy val app = (projectMatrix in file("app"))
  .dependsOn(core % "compile->compile;test->test")
  .settings(
    name := "app"
  )
  .jvmPlatform(scalaVersions = Seq("2.12.10"))
 
lazy val core = (projectMatrix in file("core"))
  .settings(
    name := "core"
  )
  .jvmPlatform(scalaVersions = Seq("2.12.10", "2.13.1"))

Project にある機能の一つとして .configure(...) メソッドというものがある。これは Project => Project 関数の可変長引数を受け取り、順次適用するだけのものだ。僕が取り扱っているビルドにこれがたまに出てくるので .configure(...) があると Project から ProjectMatrix に移植しやすくなる。

Lightbend での6年

2014年3月に Lightbend社 (当時 Typesafe社) に入社した。信じられないような 6年の後、2020年4月7日をもって退職となった。Lightbend、パートナー各社、顧客、そしてカンファレンスなどで出会った色んな人とつながりを持ったり一緒に作業する機会をもらえたのは感謝している。振り返ると COVID-19前の時代でヨーロッパ、アジア、北米などを数ヶ月ごとに飛び回ってカンファレンスに出たり社内合宿を行っていたのが現実離れして感じる。

ユーザランドでの警告とエラー、パート2

先週は、Scala でユーザランドから警告を出す仕組みの提案である #8820 について書いた。例として ApiMayChange アノテーションを実装した。これは始めとしては一応使えるけども、少し冗長だ。もしなんらかの API ステータスが頻繁に使われる場合、ライブラリ作者が独自のステータスアノテーションを定義できると嬉しいと思う。今日はその方法を考える。

Scala におけるユーザランドでのコンパイラ警告

in

一ライブラリ作者として、Scala でメソッドをタグ付けしてカスタムのコンパイラ警告やエラーを発動できるといいなと前から思っている。先週末 #8820 を scala/scala に送って @apiStatus というユーザーランドでコンパイラ警告やエラーを出せる仕組みを再提案した。

Giter8 0.12.0

giter8.version

Giter8 0.12.0 に giter8-launcher という小さなアプリを追加した。このアプリの目的は Giter8 テンプレートの振る舞いを予測可能にすることにある。現状だと、テンプレート作者が Giter8 バージョン X を想定してテンプレートを作ったとしてもユーザー側は "sbt new" に同梱される別な Giter8 バージョン Y を使って実行されている。

sbt の良いアイディアの一つにユーザーがどのバージョンの sbt スクリプトをインストールしていてもコアの sbt バージョンはビルド作者が project/build.properties ファイルを使って指定できるというものがある。これによって「自分のマシンでしか動作しない」問題が大幅に改善される。giter8-launcher は sbt における sbt-launcher に同様のものだ。giter8-launcher はテンプレートのクローンして、project/build.properties ファイルを読み込んで、テンプレートのレンダリングに用いる実際の Giter8 バージョンを決定する。

Syndicate content