haskell-jp / random #102 at 2023-02-13 16:56:03 +0900

DeepFlow 社内で開発して2年ほど使っていた、Haskell 製巨大モノレポの依存関係チェックツール guardian を OSS 化したので宣伝させてください。

https://github.com/deepflowinc/guardian

大量のパッケージから成るモノレポで開発を進めていると、不用意にパッケージ間の依存関係を増やした結果不必要にビルドに時間がかかってしまい、ちょっとした変更でもビルドに時間がかかってイテレーションが阻害される、という事がしばしばあります。
guardian はパッケージを複数のグループ（ドメイン）に分けて、予め指定されたグループ間の依存関係以外を発見すると警告してくれる、というツールです。stackベースと cabal-install ベースのプロジェクトに対応しています。
CI で手軽に呼ぶためのビルド済バイナリや、GitHub Action も用意しています。

詳細は以下の記事で紹介させて頂いておりますので、巨大 Haskell モノレポの依存関係の管理にお悩みの方のお役に立てれば幸いです:pray:

https://zenn.dev/deepflow_tech/articles/secure-haskell-monorepo-deps-with-guardian

highlevel だけが、型クラスを定義して提供するのですか？

場合によりますね。ここでは説明のために単純化して示しているので、実際にはプロジェクトの目的・構造に応じて取り決める形です。

highlevelの役割は、APIを定義し、提供することですか？

上の例では基本的にそういうことですね。記事で書いているように、

• highlevel: バックエンドや方程式系、プラグインなどの高水準な抽象化

がこの例での highlevel の役割です（これ以上詳しい説明はプロジェクトの詳細に立ち入ることになるのでご容赦ください）。
繰り返しになりますが、ドメインの一覧は決め打ちではないので、プロジェクトごとに適切なドメインの集合とトポロジーを定義することになります。

highlevelで型クラスを定義して、lowlevelで実装をして、solverでくっつけると、orphan instance になりませんか？

ならないですね。ソルバで使うバックエンドの lowlevel な定義のところでインスタンスを定義するので。

実装が抽象に依存できるので

見直すとたしかにちょっと階層図が不完全ですね。単純化の過程でちょっと抜けてました。

Orphan インスタンスを極力さけよう、というのは Haskell の基本的なプラクティスなので、そういった状況をある程度避けるように階層は設計することになります

うーん。それだと lowlevel から highlevel への (型クラスを使う)矢印が抜けていることになりませんか？

入れ違いになりました。不完全というのであれば、理解できます。

弱い依存関係があると理解しておきます。