読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

memo: sbt 0.13.x、sbt サーバー、sbt 1.0 の動向 #ScalaMatsuri

memo: sbt 0.13.x、sbt サーバー、sbt 1.0 の動向 #ScalaMatsuri

@eed3si9n

  • 2010年から
  • ScalaMatsuri 翻訳とか
  • 独習Scalaz
  • scalaxb
    • .NETの世界からくるとXMLとか不便なところある
  • treehugger.scala
  • sbt-assembly
  • sbt-buildinfo
    • 週末を中心に開発していた
  • Lightbend
  • reactive platform
  • アドオンで商用機能を使うようになった
  • 特化
  • ビルド

今日の流れ

  • sbt server
  • sbt 0.13.x tech previews おさらい
  • sbt 1.0.x に向けての展望

sbt server reboot

  • sbt server リブート
  • ブログを読んでるひとにはあんまり斬新さがないかも
  • activatorを起動するためのsbt
  • 機能を入れすぎて反省
  • 別のsbtを作る

sbt serverとは

  • single JVM process
  • implemented as a command, sort of
  • JSON API to drive sbt from network

  • forkingを行って裏でsbtサーバが走る→サーバを探すのが面倒

  • コマンドとしてsbtのサーバを実装することにした

  • サーバのプロセス→JSONを使って外部からネットワーク越しに起動する

  • IDEとの統合/分散ビルドの点でうれしい
  • エコシステムにおける役割分担
  • sbtの作者というよりはLightbend社員としてやっており、ビルドツールのどれかが隆盛してくれたらいいし、Scalaを盛り上げるのが目的
    • IDEからsbt serverできたほうがよい
    • distributed build 分散してビルドできたほうが良い
    • 0秒コンパイルの仕組みを作りたい
  • 今あるサーバはマルチクライアントシングルサーバ
  • 2つのクライアントをサポートする仕組み

仕組み

  • メインループの流れ
    • デフォルトでshellというコマンドが走っている
    • shell prompts the user
  • shellというコマンドがユーザーからコマンドを受け取る かなりマニアックなことをやっている
  • これをサーバに置き換えたらいいんじゃないかって思った
  • 裏でスレッドが走っている
  • shell→serverに代替すれば、sbt server rebootを実現できる

デモ

  • sbt server
  • serverPortでポートを設定できる
  • telnet 127.0.0.1 5173
    • channelName: channel-1を含むJSONデータが返ってくる
    • 人間がタイプするのをJSONに置き換える
  • エンドユーザーから見るとJSONを直接ごにょごにょすることはない
  • sbt client(仮)
    • sbt client 127.0.0.1:5173
    • 将来的に2つのsbtプロセスに分けたほうがいいかも
    • 分けないとシンプルになるけどユーザーが自分で立ち上げないといけない
    • thinクライアントがあって、別のプロセスでサーバを立ち上げるようにしたい
  • コンパイルの作業
    • compileタスクの入力はソース、出力はファイルと画面表示
    • return typeなんて使わなくって、クラスファイルとか出てくるwarningとかをユーザーは知りたい
  • testを打ち込むとOK/NGを返してくれる
  • だいたいのタスクの出力はディスクと画面への副作用
    • それをネットワークに抽象化するにはsemantic logging/event loggingをつかう
    • 直接stringを送るのではなく、疑似case classを送ることでうまいこと処理できるんじゃないか
  • ログでアウトプットするのが変わってくるのではないか

sbt 0.13.x tech previews

0.13.5以降について

  • sbt1になったときに詰め込みすぎると不安定になるので、13シリーズにあるだけ詰め込んでテストしたい
  • sbt1への移行は小さく

  • 13.6

    • name hashing
    • https by default
  • 13.7
    • natural whitespace handling
    • cached resolution
  • 13.8
    • cross-version
    • sequential tasks 逐次タスク
    • maven resolver
  • 13.11
    • dotty support
    • configurable compiler bridge
    • inter-project dependency tracking
    • sbt はscala 2.10
    • 簡単に言うとsbtはJavaをアセンブリぽく使う
    • Scalaのバージョンは関係なくコンパイルできる
    • dottyのbridgeを書く
  • 13.12
    • deprecates project/Build.scala(なんでやったの? build.sbtでぜんぶできるから。2つ残すとめんどくさいからbuild.sbtだけを残した)
    • scalaVersion enforcement
  • 13.13
    • sbt new
    • synthetic subprojects プロジェクトから子プロジェクトを派生→開発環境を作るときに裏でDBを走らせるみたいなことをプラグインからできる
    • <<=/<+=/<++=を廃止勧告
  • 13.14
    • Java 9 compatibility bashのほうでやるかもしれない bash/jarを組み込むことでjava9が動く
    • Other bug fixes

0.13 lesson learned

  • プラグイン環境を作るにはバイナリ互換性が重要
    • 裏を変えずにごにょごにょできるから
    • メンテするのがしんどいのがデメリット
    • コードが汚くなっていくのもつらい
    • バグの温床 メンテが難しい
  • incremental compiler
  • dependency
  • ほぼ全部の機能が新しく入れ替わるので新陳代謝が激しい=諸行無常

sbt 1.0

  • less is more

  • 少なめにやったほうが安定性が高い

  • いらない機能はどんどん捨てていく(bridgeとか)
  • scala 2.9もコンパイルできなくする
  • 途中からscala 2.10も捨てるかも

  • scala 2.12を入れる

  • 諸行無常への対応としてのモジュール化
  • 今のsbtはすべてソースを公開している→バイナリ互換性を保つのがしんどい
  • ほかの人が直そうとしても直せない
  • Zinc API/librarymanagement API/IO API
    • エコシステムを破壊しないで済む
  • Zinc API
    • Scalaコンパイラを駆動するための統一API
    • ほかのツールを作っている人でも使えるようにする
    • Zincのみをcontributeできるように
  • librarymanagement API
    • free of Ivy
  • インパクト
    • 短期的には移植コストはあると思う
    • 差分コンパイルはZyncで高速化すると思う(5-10倍)
    • 長期的にはツール環境が良くなる
  • プラグイン作者
    • JSON compatibility
    • 使っているプラグインによってはJSONの名前が不変になるかも
  • 課題
    • エコシステムの作り直しに伴う検証
    • いまあるものでコンパイルできるようにする