並列クロスビルドサンドイッチ

sbt-projectmatrix は sbt のクロスビルドを改善するために、僕が実験として作っているプラグインで、本稿は第1回、第2回、第3回に続く第4弾だ。0.6.0 をリリースしたのでここで紹介する。

おさらい: 複数の Scala バージョンに対するビルド

sbt-projectmatrix をビルドに追加後、以下のようにして 2つの Scala バージョンを使ったマトリックスをセットアップする。

ThisBuild / organization := "com.example"
ThisBuild / scalaVersion := "2.12.10"
ThisBuild / version      := "0.1.0-SNAPSHOT"

lazy val core = (projectMatrix in file("core"))
  .settings(
    name := "core"
  )
  .jvmPlatform(scalaVersions = Seq("2.12.12", "2.13.3"))

これはそれぞれの scalaVersion にサプブロジェクトを作る。 ++ スタイルのステートフルなクロスビルドと違って、これは並列にビルドする。これは変わっていない。

前回では % を使って依存性をスコープ付けできることを紹介した。

0.6.0 での新機能: よりシンプルなプロジェクトID

JVM2_13 というサフィックスを追加する代わりに、sbt-projectmatrix 0.6.0 より JVM 軸と 2_13 軸はデフォルトとして、coreJVM2_13 でなはく普通に core とか util という名前のサブプロジェクトを生成することにした。

0.6.0 での新機能: 2.13-3.0 サンドイッチのサポート

Scala 3.0 は組み込みで Scala 2.13.x に対するインターオペラビリティを持ち、2.13.x ブランチでも最近になって TASTy reader という Scala 3.0 インターオペラビリティ機能が追加された。詳細は省くとして、これを用いて 1つのサブプロジェクトは Dotty 別のサプブロジェクトは 2.13 を使うといったことが可能となる。

Twitter に入社しました

本日付けで Twitter の Build Team に入社しました。世界中にいる Twitter 社のデベロッパーをサポートする次世代ビルド・システムの構築に関わることになります。

このチームはモノリポ・ビルドツールである Pants の開発に関わっていて、社内のシステムを Bazel へ移行させるのが当面の責務となると思います。デベロッパー・エクスペリエンスや開発効率ということに関して熱い思いを持っているチームと一緒に働けるという、僕が願っていた仕事なので、チームの人たちや新しい課題との出会いを楽しみにしています。

また、この場を借りて過渡期に DM などで、大丈夫にしてるかとか、社内で僕のことを推薦してくれたり、プロジェクトのオファーなど色々声をかけてくれた皆さんに感謝したいです。そんな声があったので元気にやってこれました。ありがとうございます。4月に義務サバティカルが始まってから、これまで時間が無くてできなかったビルドキャッシュとか Selective functor みたいな作業をしたり、Scala Center の素晴らしい方々とコラボすることができたので、そういう意味では色々良かったなと思います。

EE Build team は「San Francisco, Remote US」というロケーションからまだ募集中みたいなので、興味のある人は応募して一緒に作業しましょう。

Travis-CI からの sbt プラグインの自動公開

本稿では Ólafur さんの olafurpg/sbt-ci-release を使って sbt プラグインのリリースを自動化してみる。sbt-ci-release の README は Sonatype OSS 向けの普通のライブラリのリリースを前提に書かれている。sbt プラグインのリリースに必要な差分以外の詳細は README を参照してほしい。

リリースを自動化することそのものがベスト・プラクティスだが、sbt プラグインのリリースに関連して特に嬉しいことがある。この方法を使うことで Bintray の sbt organization にユーザーを追加せずに、複数人で sbt プラグインのリリース権限を共有することが可能となる。これは仕事でメンテしているプラグインがあるときに便利だ。

step 1: sbt-ci-release

sbt-release を使っている場合は削除する。sbt-ci-release を追加する。

addSbtPlugin("org.foundweekends" %% "sbt-bintray" % "0.5.6")
addSbtPlugin("com.geirsson" % "sbt-ci-release" % "1.5.3")

version.sbt も削除する。

step 2: -SNAPSHOT version

sbt-dynver を多少抑えて、タグの付いていないコミットで -SNAPSHOT バージョンを使えるようにする:

ThisBuild / dynverSonatypeSnapshots := true
ThisBuild / version := {
  val orig = (ThisBuild / version).value
  if (orig.endsWith("-SNAPSHOT")) "2.2.0-SNAPSHOT"
  else orig
}

step 3: sbt-bintray セッティングを復活させる

プラグインは通常 sbt-bintray を使ってリリースするので、publishTo を bintray / publishTo に戻す。publishMavenStyle を false にする。

  publishMavenStyle := false,
  bintrayOrganization := Some("sbt"),
  bintrayRepository := "sbt-plugin-releases",
  publishTo := (bintray / publishTo).value,

step 4: bintrayReleaseOnPublish オーバーライドの削除

publish が自動的にリリースするようにしてほしいので、現在 bintrayReleaseOnPublish := false を設定している場合はそれを削除する。

Defx: Neovim のためのファイル・エクスプローラー・プラグイン

sbt 1.3.12

sbt 1.3.12 パッチリリースをアナウンスする。リリースノートの完全版はここにある - https://github.com/sbt/sbt/releases/tag/v1.3.12 。

特に Scala Center にお礼を言いたい。バグ報告、pull request レビュー、コントリビューションがちゃんと正しい所に行くかなどメンテ活動を行うにはある程度時間がかかるが、5月中の sbt のメンテ活動は Scala Center がスポンサーしてくれた。Daryja さん始め Scala Center のメンバーは皆気軽に共同作業しやすい人たちだ。

sbt 1.3.11 からの変更点

sbt 1.3.11 で launcher 統合周りにリグレッションがあり、repositories ファイルが無視されるという形のバグが出た。sbt 1.3.12 はそれを修正する。 #5583

アップグレード方法

通常は project/build.properties を

sbt.version=1.3.12

と書き換えるだけで ok だ。しかし、リリースにスクリプトの修正が含まれている場合もあり、また全ての JAR ファイルが予め入った *.(zip|tgz|msi) を使ったほうが初回の依存性解決が速くなるためインストーラーを使ったインストールを推奨する。インストーラーは SDKMAN などに公開される。

sdk upgrade sbt

Homebrew に関する注意

Homebrew のメンテナはもっと brew 依存性を使いたいという理由で JDK 13 への依存性を追加した brew#50649。そのため、PATH が通っている java が JDK 8 や 11 であっても sbt が JDK 13 で実行されるようになってしまう。

sbt が JDK 13 で実行するのを回避するには jEnv をインストールするか、SDKMAN に乗り換える必要がある。

sbt 1.3.11

sbt 1.3.11 パッチリリースをアナウンスする。リリースノートの完全版はここにある - https://github.com/sbt/sbt/releases/tag/v1.3.11 。

特に Scala Center にお礼を言いたい。バグ報告、pull request レビュー、コントリビューションがちゃんと正しい所に行くかなどメンテ活動を行うにはある程度時間がかかるが、5月中の sbt のメンテ活動は Scala Center がスポンサーしてくれた。Daryja さん始め Scala Center のメンバーは皆気軽に共同作業しやすい人たちだ。

アップグレード方法

通常は project/build.properties を

sbt.version=1.3.11

と書き換えるだけで ok だ。しかし、リリースにスクリプトの修正が含まれている場合もあり、また全ての JAR ファイルが予め入った *.(zip|tgz|msi) を使ったほうが初回の依存性解決が速くなるためインストーラーを使ったインストールを推奨する。インストーラーは SDKMAN などに公開される。

sdk upgrade sbt

Homebrew に関する注意

Homebrew のメンテナはもっと brew 依存性を使いたいという理由で JDK 13 への依存性を追加した brew#50649。そのため、PATH が通っている java が JDK 8 や 11 であっても sbt が JDK 13 で実行されるようになってしまう。

sbt が JDK 13 で実行するのを回避するには jEnv をインストールするか、SDKMAN に乗り換える必要がある。

主な変更点

sbt 1.3.11 は lm-coursier を 2.0.0-RC6-4 へとアップグレードし、これはキャッシュの場所としての $HOME/.coursier/cache ディレクトリを廃止して、OS に特定のディレクトリを使うようになる:

Jar Jar Abrams

Jar Jar Abrams は、Java ライブラリをシェーディングするユーティリティである Jar Jar Links の実験的 Scala 拡張だ。

ライブラリ作者にとって他のライブラリは諸刃の剣だ。他のライブラリを使うことは作業の二重化を避け、他のライブラリを使いたくないというのはダブルスタンダードと言われかねない。しかし、その一方で、ライブラリを追加する度にそれはユーザ側にすると間接的依存性が追加されたことになり、衝突が起こる可能性も上がることになる。これは単一のプログラム内において 1つのバージョンのライブラリしか持てないことにもよる。

このような衝突はプログラムがランタイムやフレームワーク上で実行される場合によく起こる。sbt プラグインがその例だ。Spark もそう。1つの緩和策として間接的ライブラリを自分のパッケージの中にシェーディングするという方法がある。2004年に herbyderby (Chris Nokleberg) さんは Jar Jar Links というライブラリを再パッケージ化するツールを作った。

2015年に Wu Xiang さんが Jar Jar Links を使ったシェーディングのサポートを sbt-assembly に追加した。これは前向きな一歩だったが、課題も残っていた。問題の 1つは Scala コンパイラは ScalaSignature 情報を *.class ファイルに埋め込むが、Jar Jar がそのことを知らないことだ。2020年になって Simacan社の Jeroen ter Voorde さんが ScalaSignature の変換を sbt-assembly#393 にて実装した。sbt 以外でもこれは役に立つかもしれないので、独立したライブラリに抜き出した。これが Jar Jar Abrams だ。

core API

コアには shadeDirectory 関数を実装する Shader オブジェクトがある。

package com.eed3si9n.jarjarabrams

object Shader {
  def shadeDirectory(
      rules: Seq[ShadeRule],
      dir: Path,
      mappings: Seq[(Path, String)],
      verbose: Boolean
  ): Unit = ...
}

この関数は、dir が JAR ファイルを展開したディレクトリであることを期待する。

sbt での Selective ファンクター

sbt コア・コンセプトのトークをするとき僕は sbt をカジュアルに関数型なビルド・ツールと言っている。関数型プログラミングの 2つの特徴としてデータを変化させるのではなく immutable (不変)なデータ構造を使うことと、いつ、どのようにして effect (作用) を取り扱うかに気を使っていることが挙げられる。

セッティングとタスク

その観点から見ると、セッティング式とタスクはその 2点に合致していると考えることができる:

• セッティング列はビルドの不変グラフを形成する。
• タスクは作用を表す。

匿名セッティングは Initialize[A] で表され、以下のようになっている:

  sealed trait Initialize[A] {
    def dependencies: Seq[ScopedKey[_]]
    def evaluate(build: BuildStructure): A // approx
    ....
  }

名前の付いたセッティングは Setting クラスで表される:

  sealed class Setting[A] private[Init] (
      val key: ScopedKey[A],
      val init: Initialize[A],
      val pos: SourcePosition
  ) ....

sbt.Task は副作用関数 () => A のラッパーだと便宜的に考えていい。ただし、僕たちが「compile はタスクだ」と言うとき、の文脈でのタスクは Initialize[Task[A]] で表される。つまり、これは Task[A] 型を返すセッティングだ。

これは Def.task の戻り型 Def.Initialize[Task[A]] を見ることで確認することができる。

Applicative 合成

Def.task はタスク (Def.Initialize[Task[A]]) の Applicative 合成をエンコードするためのマクロだ。以下の task1、task2、task3 を考察する:

lazy val task1 = taskKey[Int]("")
lazy val task2 = taskKey[Int]("")
lazy val task3 = taskKey[Int]("")

task1 := 1
task2 := 2

task3 := {
  val t1 = task1.value
  val t2 = task2.value
  t1 + t2
}

これを旧タプル構文で書き下すとこうなる:

sbt で約束 (promise) を守る

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

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

通常は task1 をサブタスクに分けることでこれを解決する。しかし、それを実装するのは一筋縄ではいかないこともある。例えば、Zinc に半分だけコンパイルして、残りは後で続けて下さい? もしくは Coursier に解決だけ行って実際のダウンロードは後でとどう言えばいいだろうか?

たたき台として task1 が何らかの JSON ファイルを生成して、task2 はファイルが現れるまで待って、それを読み込むというやり方が考えられる。JSON ファイルの代わりに Promise[A] のような並行データ構造を使って改善することができる。しかし、待機という厄介なものが残っている。sbt は並列に実行するタスクの数を限っているので、待機のために枠を使うのはもったいない。Daniel さんの Thread Pools にこの辺りの事が良くまとまっている。今回あるのは差し当たり作業を一切行わないブロッキング IO ポーリングと考えることができると思う。

Def.promise

scala.concurrent.Promise のラッパーを実装して Def.promise と呼んだ。具体例で説明する:

val midpoint = taskKey[PromiseWrap[Int]]("")
val longRunning = taskKey[Unit]("")
val task2 = taskKey[Unit]("don't call this from shell")
val joinTwo = taskKey[Unit]("")

// Global / concurrentRestrictions := Seq(Tags.limitAll(1))

lazy val root = (project in file("."))
  .settings(
    name := "promise",
    midpoint := Def.promise[Int],
    longRunning := {
      val p = midpoint.value
      val st = streams.value
      st.log.info("start")
      Thread.sleep(1000)
      p.success(5)
      Thread.sleep(1000)
      st.log.info("end")
    },
    task2 := {
      val st = streams.value
      val x = midpoint.await.value
      st.log.info(s"got $x in the middle")
    },
    joinTwo := {
      val x = longRunning.value
      val y = task2.value
    }
  )

まず、midpoint という PromiseWrap[Int] のタスクを作る。コマンド呼び出しの度にフレッシュな promise が欲しいのでタスクを使う。次に、longRunning というタスクがあって、これは途中で promise を補完する。task2 は midpoint.await.value に依存する。これは、midpoint に格納された promise が完了するまで sbt のスケジューラーは task2 を開始しないことを意味する。

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

Google のビルドインフラ Blaze (現在は Bazel としてオープンソース化されている) のことを知ってから Scala のツールチェインにも似たような仕組みが欲しいとずっと思い続けてきた。これは特に独創的な発想という訳では無く、Peter Vlugter さんと Ben Dougherty さんの nailgun Zinc での機能 (Pants で使われていた?) や、Krzysztof Romanowski さんの Hoarder など先行研究もある。それらは、作業ディレクトリに合わせて Zinc Analsis ファイル内に格納されている絶対パスを変換するというアイディアから成り立っている。

僕の作業の詳細に入る前に、問題スペースをざっとデモしよう。

ビルドのマシン依存性

Akka の akka-actor/compile を sbt 1.3.10 でビルドするとこのようになる:

cd ~/work/quicktest/
git clone git@github.com:akka/akka.git akka-0
cd akka-0
sbt
akka > akka-actor/compile
[info] Generating 'Tuples.scala'
[info] Generating 'Functions.scala'
[info] Updating
[info] Resolved  dependencies
[info] Updating
[info] Formatting 22 Java sources...
[info] Reformatted 0 Java sources
[info] Compiling 191 Scala sources and 28 Java sources to /Users/eed3si9n/work/quicktest/akka-0/akka-actor/target/scala-2.12/classes ...
....
[success] Total time: 39 s, completed May 6, 2020 1:53:36 PM

別の人が同じことをやるのを再現したいので、このディレクトリごと別の場所にコピーする:

Zinc 1.4.0-M1

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

• Zinc を Scala 2.12 と 2.13 へとクロスビルドした zinc#754 by @eed3si9n
• ScalaPB を 0.9.3 へとアップグレードした zinc#713 by @slandelle
• ZipUtils 内での java.util.Date の使用を java.time 系へと置き換えた zinc#714 by @slandelle

Zinc は Scala のための差分コンパイラだ。Zinc は Scala 2.10 ~ 2.13 と Dotty をコンパイルすることが可能だが、これまでの所 Zinc そのものは Scala 2.12 で実装されてきた。これは Scala 2.12 で実装されている sbt 1.x としては問題無いが、Zinc を 2.13 でもクロスビルドして欲しいという要望は前からあった。

どうやら Gatling は Zinc をライブラリとして使っているらしく、Gatling のコア開発者の Stephane Landelle さんはアップデートに必要なパッチを送ってくれた。最後に僕がする必要があった作業は入り組んだサブプロジェクトを解きほぐして再配線することだが、それには僕が昨日書いた sbt-projectmatrix を使った。

Li Haoyi さんも Mill を Scala 2.13 で書くのにこれを待っているらしい。お楽しみ下さい :)

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

sbt-projectmatrix は sbt のクロスビルドを改善するために、僕が実験として作っているプラグインで、本稿は前々回、前回に続く第3弾だ。0.5.0 をリリースしたのでここで紹介する。

おさらい: 複数の Scala バージョンに対するビルド

sbt-projectmatrix をビルドに追加後、以下のようにして 2つの Scala バージョンを使ったマトリックスをセットアップする。

ThisBuild / organization := "com.example"
ThisBuild / scalaVersion := "2.12.10"
ThisBuild / version      := "0.1.0-SNAPSHOT"

lazy val core = (projectMatrix in file("core"))
  .settings(
    name := "core"
  )
  .jvmPlatform(scalaVersions = Seq("2.12.10", "2.11.12"))

これは coreJVM2_11 と coreJVM2_12 というサブプロジェクトを作る。 ++ スタイルのステートフルなクロスビルドと違って、これは並列にビルドする。これは変わっていない。

前回では列で複数の次元を表現できる VirtualAxis を紹介した。

0.5.0 での新機能

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前の時代でヨーロッパ、アジア、北米などを数ヶ月ごとに飛び回ってカンファレンスに出たり社内合宿を行っていたのが現実離れして感じる。

以下は過去6年の簡単な振り返りだ。

2014

Scala を趣味で始めたのは 2009年の終わり頃なので、2014年の時点では 4年ぐらいは書いていたのではないか。丁度「独習 Scalaz」が終わって、関連するネタで最初の nescala のトークを行った。10個ぐらいの sbt プラグインを作って、Stackoverflow でも良く活動してた。

3月に Lightbend社のツーリングチーム (当時は Typesafe社「Q課」) に入社した。当時のメンバーは Josh Sereth と Toni Cunei。Josh と sbt のメンテをするのは確かに仕事の分担だけども、仕事は戦略もしくは、難関というか、学びの多い顧客ドリブンなものが大半だった。入社した直後に顧客先に国内線で飛んで、Apache Ivy のコードを読んだりプロファイリングしたりしたのを覚えている。最初は面食らったが、すぐに sbt の中ではライブラリ依存性周りが最も慣れようになった。

2014年5月には sbt のバージョン番号を 0.13.2 から 0.13.5 と飛ばして sbt 1.x シリーズのテクノロジーレビューとした。必要な機能を実験的に導入していくことで sbt 1.x との差が大きくなり過ぎないようにするというアイディアだった。

sbt 0.13.6 になって、未解決の依存性のエラーを足りない依存性の木で表示したり、eviction warning、updateOptions での withLatestSnapshots など僕が追加したライブラリ依存性周りの機能が出てくるようになる。

2014年後半には Q課は Typesafe Reactive Platform v1 のためのインフラ作りを行った。これは Toni が実装した Dbuild を元にした商用配布パッケージだ。

2015

2015年3月、Josh と一緒に僕の最初の Scala Days のトーク ‘The road to sbt 1.0 is paved with server’ を行った。当時の僕から見ると Josh には sbt に関する無限の知見に富んでいるように見えた。

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

先週は、Scala でユーザランドから警告を出す仕組みの提案である #8820 について書いた。例として ApiMayChange アノテーションを実装した。

package foo

import scala.annotation.apiStatus, apiStatus._

@apiStatus(
  "should DSL is incubating, and future compatibility is not guaranteed",
  category = Category.ApiMayChange,
  since = "foo-lib 1.0",
  defaultAction = Action.Warning,
)
implicit class ShouldDSL(s: String) {
  def should(o: String): Unit = ()
}

これは始めとしては一応使えるけども、少し冗長だ。もしなんらかの API ステータスが頻繁に使われる場合、ライブラリ作者が独自のステータスアノテーションを定義できると嬉しいと思う。今日はその方法を考える。

その前に少し裏方の解説を必要とする。コンパイラがアノテーションを見る時この情報は AnnotationInfo として渡され、引数は構文木で表される。これによってコールサイトのソースコードはあるが、アノテーションのコードがコンストラクタで何かやったなどの事は分からない。一方、アノテーションクラスにタグ付けされたアノテーションのことは分かる。

ApiMayChange の実装再び

アノテーションのに付けることを前提に作られたアノテーションはメタアノテーションと呼ばれ、これを使うことで apiStatus の継承を行うことができる:

import scala.annotation.{ apiStatus, apiStatusCategory, apiStatusDefaultAction }
import scala.annotation.meta._

@apiStatusCategory("api-may-change")
@apiStatusDefaultAction(apiStatus.Action.Warning)
@companionClass @companionMethod
final class apiMayChange(
  message: String,
  since: String = "",
) extends apiStatus(message, since = since)

category や defaultAction を extends apiStatus(....) で渡すのではなく @apiStatusCategory と @apiStatusDefaultAction を使って指定する。

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

一ライブラリ作者として、Scala でメソッドをタグ付けしてカスタムのコンパイラ警告やエラーを発動できるといいなと前から思っている。何故意図的にコンパイラエラーを出す必要があるのかと思うかもしれない。一つのユースケースとしては、API を廃止した後でマイグレーションのためのメッセージを表示させることだ。

Restligeist macro: n. A macro that fails immediately to display migration message after implementation has been removed from the API.

— ∃ugene yokot∀ (@eed3si9n) August 30, 2016

僕はこれを Restligeist macro、つまり地縛霊マクロと呼んでいる。例えば、sbt 1.3.8 において <<= を使うと以下のエラーメッセージが起動時に表示される。

/tmp/hello/build.sbt:13: error: `<<=` operator is removed. Use `key := { x.value }` or `key ~= (old => { newValue })`.
See http://www.scala-sbt.org/1.x/docs/Migrating-from-sbt-013x.html
    foo <<= test,
        ^
[error] sbt.compiler.EvalException: Type error in expression
[error] Use 'last' for the full log.
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?

これ実現可能というのは良いことだけども、わざわざマクロを使わなければいけないのいうのが仰々しい。吉田さんによると Haskell だとこれぐらいのことは型シグネチャに Whoops と書くだけでできるらしい:

-- | This function is being removed and is no longer usable.
-- Use 'Data.IntMap.Strict.insertWith'
insertWith' :: Whoops "Data.IntMap.insertWith' is gone. Use Data.IntMap.Strict.insertWith."
            => (a -> a -> a) -> Key -> a -> IntMap a -> IntMap a
insertWith' _ _ _ _ = undefined

configurable な警告

2019年3月に僕は scala/scala に #7790 という pull request を送って @compileTimeError というアノテーションを提案した。レビューの流れを受け入れているうち pull request は @restricted アノテーションと configurable な警告オプション -Wconf というものに変わっていった。@restricted はラベルによってメソッドのタグ付けを行い、-Wconf はそのタグを -Wconfig apiMayChange:foo.*:error というふうにして警告やエラーにエスカレートさせることができるというものだ。

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 バージョンを決定する。

テンプレート作者は project/build.properties ファイルを用いて以下のように Giter8 バージョンを指定できる:

giter8.version=0.12.0

VirtualAxis を用いた並列クロスビルド

sbt-projectmatrix は sbt のクロスビルドを改善するために、僕が実験として作っているプラグインで、本稿は前篇に続く第2弾だ。0.4.0 をリリースしたのでここで紹介する。

おさらい: 複数の Scala バージョンに対するビルド

sbt-projectmatrix をビルドに追加後、以下のようにして 2つの Scala バージョンを使ったマトリックスをセットアップする。

ThisBuild / organization := "com.example"
ThisBuild / scalaVersion := "2.12.10"
ThisBuild / version      := "0.1.0-SNAPSHOT"

lazy val core = (projectMatrix in file("core"))
  .settings(
    name := "core"
  )
  .jvmPlatform(scalaVersions = Seq("2.12.10", "2.11.12"))

これは coreJVM2_11 と coreJVM2_12 というサブプロジェクトを作る。 ++ スタイルのステートフルなクロスビルドと違って、これは並列にビルドする。これは変わっていない。

前篇ではこの考え方をクロス・プラットフォームやクロス・ライブラリへと応用させることを考えた。

0.2.0 の問題

Support for mixed-style matrix dependencies #13 と Support for pure Java subprojects #14 という 2つの issue が立てられて、0.2.0 の設計に限界があることに気づいた。0.2.0 は各列は以下のように表現される:

final class ProjectRow(
    val idSuffix: String,
    val directorySuffix: String,
    val scalaVersions: Seq[String],
    val process: Project => Project
) {}

これは、列が追跡できるもの (例えばプラットフォーム) を 1つの次元とプラスで特定の Scala バージョンに限定する。報告された issue はマトリックス内の列を別のマトリックス内の列へと少し弱めた制限を用いて関連付けようとしていると意味で同じ問題の変種であると言える。

Pamflet 0.8.2

Pamflet は短い文書、特にオープンソース・ソフトウェアの ユーザ・ドキュメントを公開するためのアプリだ。

Pamflet 0.8.2 はモノスペースのタイプフェイスを SFMono へと変更する。また、Blueprint から Bootstrap に移行したときに不意に導入されたピンクの文字色を元に戻す。

依存性解決のセマンティクス

依存性リゾルバー

依存性リゾルバー (dependency resolver)、もしくはパッケージマネージャーは、ユーザーによって与えられた制約の集合を元に矛盾しないモジュールの集合を決定するプログラムだ。通常この制約要件はモジュール名とそれらのバージョン番号を含む。JVM エコシステムにおける Maven モジュールは organization (group id) も指定に用いられる。その他の制約として、バージョン範囲、除外モジュール、バージョンオーバーライドなどもある。

パッケージングは大まかに OS パッケージ (Homebrew、Debian packages など)、特定のプログラミング言語のモジュール (CPAN、RubyGem、Maven など)、特定のアプリケーションのためのエクステンション (Eclipse プラグイン、IntelliJ プラグイン、VS Code extensions など) の 3つのカテゴリーがある。

依存性解決のセマンティクス

考え始めの近似としてモジュール依存性を DAG (有向非巡回グラフ) だと考えることができる。これは依存性グラフ、もしくは “deps graph” と呼ばれる。以下のような 2つのモジュール依存性があるとする:

• a:1.0。これはさらに c:1.0 に依存する。
• b:1.0。これはさらに c:1.0 と d:1.0 に依存する。

+-----+  +-----+
|a:1.0|  |b:1.0|
+--+--+  +--+--+
   |        |
   +<-------+
   |        |
   v        v
+--+--+  +--+--+
|c:1.0|  |d:1.0|
+-----+  +-----+

a:1.0 と b:1.0 に依存すると、a:1.0、b:1.0、c:1.0、そして d:1.0 が得られる。これは木を歩いているだけだ。

sbt 1.3.0

皆さんこんにちは。sbt プロジェクトを代表して sbt 1.3.0-RC1 をアナウンスします。これは sbt 1 のフィーチャーリリース第3弾で、バイナリ互換性は維持しつつ新機能にフォーカスを当てたリリースとなっている。sbt 1 は Semantic Versioning にもとづいてリリースされるので、プラグインは sbt 1.x シリーズ中機能することが期待されている。

• 2019年3月29日までに大きな問題が見つからなければ、1.3.0-RC1 は 1.3.0 final 版となる予定だ。

sbt 1.3 の主な新機能はデフォルトでの Coursier を使ったライブラリ管理、ClassLoader レイヤリング、IO の改善、そして super shell だ。これらの機能の組み合わせがビルドのユーザーエクスペリエンスを向上することを願っている。

互換性に影響のある変更点

• Coursier を用いたライブラリ管理。詳細は後ほど。
• ClassLoader レイヤリング。詳細は後ほど。
• super shell。詳細は後ほど。
• マルチコマンドの先頭にセミコロンが要らなくなった。clean;Test/compile; で動作するようになった。 #4456 by @eatkins
• sbt.internal.inc.ZincUtil 以下の関数で LM を使うものが ZincLmUtil に移動して、Zinc から LM に依存しないようになった。 zinc#655 by @dwijnand

Coursier を用いたライブラリ管理

sbt 1.3.0 はライブラリ管理に Coursier を採用する。Coursier は、ライブラリ依存解決を行うもので Ivy に似ているが、より高速化を求めて Alexandre Archambault さん (@alexarchambault) により一から Scala でリライトされたものだ。

注意: 状況によっては Coursier の解決結果は Ivy と異なることがありえる (例えば、リモートの -SNAPSHOT は 24時間キャッシュされる)。ライブラリ管理を Apache Ivy に戻したい場合は、以下の設定を build.sbt に書くことができる:

sbt-projectmatrix を用いた並列クロスビルド

去年 sbt のクロスビルドを改善するために、sbt-projectmatrix という実験的プラグインを書いた。0.2.0 をリリースしたのでここで紹介する。

複数の Scala バージョンに対するビルド

sbt-projectmatrix をビルドに追加後、以下のようにして 2つの Scala バージョンを使ったマトリックスをセットアップする。

ThisBuild / organization := "com.example"
ThisBuild / scalaVersion := "2.12.8"
ThisBuild / version      := "0.1.0-SNAPSHOT"

lazy val core = (projectMatrix in file("core"))
  .settings(
    name := "core"
  )
  .jvmPlatform(scalaVersions = Seq("2.12.8", "2.11.12"))

これは coreJVM2_11 と coreJVM2_12 というサブプロジェクトを作る。 ++ スタイルのステートフルなクロスビルドと違って、これは並列にビルドする。

2つのマトリックス

1つ以上のマトリックスがあると面白くなる。

ThisBuild / organization := "com.example"
ThisBuild / scalaVersion := "2.12.8"
ThisBuild / version      := "0.1.0-SNAPSHOT"

// uncomment if you want root
// lazy val root = (project in file("."))
//   .aggregate(core.projectRefs ++ app.projectRefs: _*)
//   .settings(
//   )

lazy val core = (projectMatrix in file("core"))
  .settings(
    name := "core"
  )
  .jvmPlatform(scalaVersions = Seq("2.12.8", "2.11.12"))

lazy val app = (projectMatrix in file("app"))
  .dependsOn(core)
  .settings(
    name := "app"
  )
  .jvmPlatform(scalaVersions = Seq("2.12.8"))

この例では core は Scala 2.11 と 2.12 に対してビルドするが、app はそのうちの 1つのみ対応している。

git リポジトリの分岐

サブディレクトリを新しいリポジトリへ分岐させる (シンプルな場合)

git clone --no-hardlinks --branch master originalRepoURL childRepo
cd childRepo
git filter-branch --prune-empty --subdirectory-filter path/to/keep master
git remote remove origin
git prune
git gc --aggressive

originalRepoURL、master、path/to/keep などは適当な値に変える。全てのブランチを処理したい場合は -- --all を使う。

サブディレクトリを新しいリポジトリへ分岐させる (複雑な場合)

複数のパスをフィルターしたい場合は、--index-filter と brew install gnu-sed findutils によってインストールできる GNU xargs と GNU sed を使う必要がある。

git clone --no-hardlinks --branch master originalRepoURL childRepo
cd childRepo
git filter-branch --index-filter 'git rm --cached -qr --ignore-unmatch -- . && git reset -q $GIT_COMMIT -- path1/to/keep path2/to/keep' --prune-empty master
git filter-branch --prune-empty --parent-filter 'gsed "s/-p //g" | gxargs git show-branch --independent | gsed "s/\</-p /g"'
git remote remove origin
git prune
git gc --aggressive

originalRepoURL、master、path1/to/keep、path2/to/keep などは適当な値に変える。全てのブランチを処理したい場合は -- --all を使う。

君達の JDK は全て SDKMAN! がいただいた

これは Travis CI に自分で JDK をインストールする解説の第2弾だ。以前は、jabba を紹介した。

今日は SDKMAN!, という、Marco Vermeulen (@marc0der) さんが作った元気な名前のツールを見ていく。これは、JDK の他にも Groovy、Spark、sbt など JVM 上の様々なツールを対象とする環境マネージャーだ。

AdoptOpenJDK 11 と 8

• 2020-09-23 更新: バージョン番号の正規表現を更新した。
• 2019-11-06 更新: SDKMAN の更新プロンプトが CI をブロックするのを回避するために sdkman_auto_selfupdate を追加した。また、sdk install の行に || true を追加した。
• 2019-07-08 更新: パッチバージョンを自動検知するように変更した。古い版は GitHub に置いてある。

以下は SDKMAN! を使って Travis CI 上で AdoptOpenJDK 8 と 11 を用いてクロスビルドする方法だ:

dist: xenial

language: scala

scala: 2.12.10

matrix:
  include:
  - env:
      - ADOPTOPENJDK=11
  - env:
      - ADOPTOPENJDK=8

before_install:
  # adding $HOME/.sdkman to cache would create an empty directory, which interferes with the initial installation
  - "[[ -d /home/travis/.sdkman/ ]] && [[ -d /home/travis/.sdkman/bin/ ]] || rm -rf /home/travis/.sdkman/"
  - curl -sL https://get.sdkman.io | bash
  - echo sdkman_auto_answer=true > /home/travis/.sdkman/etc/config
  - echo sdkman_auto_selfupdate=true >> $HOME/.sdkman/etc/config
  - source "/home/travis/.sdkman/bin/sdkman-init.sh"

install:
  - sdk install java $(sdk list java | grep -o "$ADOPTOPENJDK\.[0-9]*\.[0-9]*\.hs-adpt" | head -1) || true
  - unset _JAVA_OPTIONS
  - unset JAVA_HOME
  - java -Xmx32m -version

script: sbt -Dfile.encoding=UTF8 -J-XX:ReservedCodeCacheSize=256M ++$TRAVIS_SCALA_VERSION! test

before_cache:
  - find $HOME/.ivy2 -name "ivydata-*.properties" -delete
  - find $HOME/.sbt  -name "*.lock"               -delete

cache:
  directories:
    - $HOME/.cache/coursier
    - $HOME/.ivy2/cache
    - $HOME/.sbt/boot
    - $HOME/.sdkman

ジョブが走ると、以下のように表示されるはずだ:

Docker での sbt

Docker 内で sbt を走らせたかったので、イメージをいくつか作った。GitHub リポジトリは eed3si9n/docker-sbt。

Pamflet 0.8.0

年末の連休中に Pamflet の left TOC (目次) を実装して、Pamflet 0.8.0 としてリリースした。

Pamflet は短い文書、特にオープンソース・ソフトウェアの ユーザ・ドキュメントを公開するためのアプリだ。

scala.Seq のマスキング

現行の Scala 2.13.0-M5 のままで行くと、scala.Seq は scala.collection.Seq から scala.collection.immutable.Seq に変更される予定だ。Scala 2.13 collections rework に何故今まで不変じゃなかったのかの解説が少し書かれている。行間から推し量ると、scala.Seq がデフォルトで不変になることを喜ぶべきだと言っているんだと思う。

デフォルトで列が不変になることはアプリや新しく書かれるコードには良いことだと思う。ライブラリ作者にとってはもう少しこみいっているかもしれない。

• あなたがクロスビルドされたライブラリを持っていて
• ライブラリのユーザも複数の Scala バージョンを使っていて
• ライブラリのユーザが Array(...) を使っていた場合

この不変 Seq への変更は、breaking change つまり非互換な API 変更となりうる。

失敗例としては scopt/scopt#218 がある。僕が scopt のクロスビルドを行ったが、args を渡せなくなったらしい。Scala 2.13.0-M5 においても args は Array[String] のままだ。

シンプルな修正は全てのソースにおいて scala.collection.Seq を import することだ。僕が欲しいのは Seq を使うとコンパイルが通らなくなることだ。

scala.Seq を unimport する

まず最初にやってみたのは scala.Seq を unimport して、scala.collection.Seq か scala.collection.immutable.Seq のどちらかを import することを強制することだ。

import scala.{ Seq => _, _ }

最も外側にあるスコープ内でデフォルトの import scala._ によって Seq という名前が束縛されているため、これは効果が無い。あと、よく考えてみると、もし仮にそれがうまくいったとしても import 文を全てのソースに忘れずに書かなければいけないので、良い手では無い。

カンファレンスを女性にとってよりセーフなスペースにするための方法

技術カンファレンスにおける女性の参加率 (やその他のバックグラウンドを持つ人の参加率) を改善するには、周辺のカルチャーを変えていく必要がある。そのためには以下の 2点に関してハッキリとしたシグナル化とコミュニケーションを必要とする

1. カンファレンスで女性参加者をナンパするのはダメ
2. 技術的な能力を前提として、女性参加者とプロフェッショナルかつ対等に接する これらは全てのカンファレンスにおいて基調講演の前と、社交タイムの前に繰り返し連絡されるべき事項だ。

sbt のための super shell

週末中に sbt のための super shell の実装がまとまってきたのでここに報告する。大まかな概要としては、ターミナル画面の下 n行を乗っ取って今走っているタスクを表示させる。

ログを現状報告に使うことの限界

ログは多くの場面で有用で、時としては何が起こっているかを知るための唯一の現実解であったりする。だけども、sbt のようなコンソールアプリにおいては、ログを使ってビルド・ユーザに現在なにが起こっているかを報告するのはうまくいかないことがある。

仮に sbt が一切ログを表示しなかったとすると、sbt が長時間走るタスクを実行して一見固まってしまったときに何が起きているか分からなくなる。そのため、update のようなタスクは “Updating blabla subproject” と “Done updating” といった開始、終了ログを表示する。update タスクはユーザやビルドによって非常に長い時間がかかってしまうことで有名だが、少ないライブラリ依存性を持つその他の多くのビルドは 1s 以内で完了する。そのような場合、ビルドの開始時に “Done updating” がズラーッと壁のように並ぶことになる。

つまり、ログ表示を現状報告に使うのはログが出すぎてうるさい状態と、情報が足りなくて不便な両極端の間を揺れることになる。

show your work (途中式を書くこと)

人生における多くの事と同様に、やったことの提示方法やユーザー・インターフェイスはその作業とかプロダクトそのものの必要不可欠な側面であり、特にその作業やプロダクトが自明で無いものほどそれが顕著になる。

僕は、sbt が単一のコマンド実行内においてタスクを並列処理することを当たり前のように考えてきた。しかし、最近になってその事を知らない人がいる場面に出くわすことが増えてきた。これは、実はもっともなことだ。なぜなら、ビルドの DSL もユーザインターフェイスも sbt がタスクの並列処理を行っていることを明らかにしていないからだ。

さらに、古参のユーザが sbt がタスクを並列実行していることを信じていたとしても、現在はどのタスクがパフォーマンスのボトルネックになっているのかを知るのが難しい。何らかのプラグインが不必要に update を呼び出したり、ソースが一切変わっていないのにプロセス外の Typescript コンパイラを呼び出したりしているかもしれない。

super shell

現在実行中のタスクを表示する “super shell” はこれらの問題を解決する。1s 以内に実行するタスクは画面には表示されず、長時間走っているタスクはカウントアップする時計が表示される。

初めて僕がこのような機能に気付いたのは Gradle の “rich console” だ。Buck もこれを実装していて、“super console” と呼ばれているらしいので、僕もその名前を借りることにした。

super shell の実装方法

一ヶ月ぐらい前に Scala で書くコンソール・ゲームを書いたが、実はそれはこの機能のための予備研究だった。

-Xlint, -Xfatal-warnings, そして Scalafix を用いた Scala の厳格化

コンパイルする、さもなければコンパイルしない。警告などいらない。最近気に入っている Scala コンパイラのフラグは "-Xlint" と "-Xfatal-warnings" の 2つだ。

以下は、サブプロジェクトと共に使えるセッティングの例だ:

ThisBuild / scalaVersion := "2.12.6"

lazy val commonSettings = List(
  scalacOptions ++= Seq(
    "-encoding", "utf8",
    "-deprecation",
    "-unchecked",
    "-Xlint",
    "-feature",
    "-language:existentials",
    "-language:experimental.macros",
    "-language:higherKinds",
    "-language:implicitConversions"
  ),
  scalacOptions ++= (scalaVersion.value match {
    case VersionNumber(Seq(2, 12, _*), _, _) =>
      List("-Xfatal-warnings")
    case _ => Nil
  }),
  Compile / console / scalacOptions --= Seq("-deprecation", "-Xfatal-warnings", "-Xlint")
)

lazy val foo = (project in file("foo"))
  .settings(
    commonSettings,
    name := "foo",  
  )

-Xlint とは?

-Xlint は色々なコンパイル警告を追加する。@smogamiさんが Scala Compiler Options というページをコントリビュートしてくれたので -Xlint が何をやっているのかを読めるようになった。

発動する警告の一例として、型引数が Any に推論されると警告する -Xlint:infer-any というのがある。

-Xfatal-warnings

警告が問題なのは、だいたい後回しにされて山積みになってしまうことだ。-Xfatal-warnings は警告をコンパイル・エラーにするので無視できなくなる。

silencer を用いた警告の抑制

ただし、警告を回避不可能な場合もある。例えば、後方互換性のために deprecated なメソッドを使う必要があるかもしれない。特定の式だけで警告を抑制できればいいと思う。

git gone: stale なローカルブランチのクリーンアップ

GitHub の pull request を中心に作業していると、やたらといらないブランチがローカルに溜まってくる。本稿では、このいらないローカルブランチを掃除する方法をみてみる。

基本的に 2つの戦略があると思う:

• “master” ブランチを選んで、そこにマージ済みのものを削除する
• GitHub 上で既にブランチは削除されている前提で、リモートの “origin” にはもう無いローカルのブランチを削除する

Erik Aybar さんの Git Tip: Deleting Old Local Branches というブログ記事は第2の方法をとっている。

This just helped clean up 150+ old local branches for me this morning, so I thought I should share! #githttps://t.co/VLKLtl5inp

— Erik Aybar (@erikaybar_) January 31, 2017

git gone

git gone は、Erik Aybar さんのテクニックをベースに僕が書いたカスタム git コマンドだ。Bash でスクリプト書くのは不慣れなので Google とか Stackoverflow を見ながら書いたが、一応動いてくれていると思う。eed3si9n/git-gone にソースを貼ったのでそれを ~/bin など適当な場所に git-gone として保存する。

使い方は git gone と打てば出てくるようにした: