goでpkgパッケージを作りたくなる派の意見

個人的にはpkgパッケージを作ることにわりと肯定的な立場なので思ったことをメモしておくよ。

pkgパッケージが作られる理由

pkgパッケージを作りたいと思う理由は以下だよ。

  • pkgパッケージはmonorepoの小さい版と解釈すると納得できる
  • 公開されたパッケージのAPIは変更しづらいがメンテし続けなくてはいけない(破壊的な変更を好まない人々の目に触れることになる)
  • internalでは全然ダメ。公開を意図してパッケージを作りたい

OSSプロジェクトで見つかるpkgパッケージの理由は真ん中の理由が主かもしれない。有名な組織の下のコードだとこなれてない段階でも依存したがる人が一定数存在していそうだし。

典型的な作成例

一方OSS関係なく自分たちのコードでpkgパッケージを作りたいと思うこともあるよ。そのようなときの典型的なpkgパッケージの内訳は以下だよ(もちろんこれらはサブパッケージだよ)。

  • 状態を持った生成系(e.g. 乱数, 現在時刻)
  • ロガー
  • 文字列 -> オブジェクト (e.g. time.Time)

application code? library (pkg)? application library (apppkg)?

場合によってはsessionIDなどを良い感じにロガーに渡すなど、アプリと自分たちの組織の慣習やインフラとが密に結びついたパッケージをapppkg的な感じで切ることもあるよ(pkg,apppkgが存在する)。

ただしこのapppkgが最終的な良い位置だとは思わないよ。すわりの悪い位置だなーということはメンバー内で納得している必要があるよ。

どうしてアプリのコードではないの?というと、アプリが複数あることもあるからだよ。

そもそもなんでpkgパッケージの要・不要が分かれるの?

作成するものがツール派とアプリ派に分かれるからだよ

ツールとは

  • 一つのことを上手くやる
  • ユーザーは開発者
  • 仕様を外部化して固定できる(e.g. RFC, ツール内の慣習)
  • UIや分岐はトップレベルのmain()でほぼ決まる

アプリとは

  • いろんなことが何でもできる
  • ユーザーは非開発者
  • 仕様を内部で良い感じにハンドリングする必要がある
  • UIや分岐はユーザーのinputに依存する

基本的にはgoはツールの方が得意だよ。でも現在頑張ってアプリに手をかけようとしている最中という認識だよ(これはアプリ開発者の疲弊とgo2.0の新機能がどこに向いているかに対する自分の認識だよ)。

まとめ

pkgパッケージはmonorepoでgoはelmだよ。