miseは異なる配布モデルをbackendで同じUXに重ねる
tool managerの設計には、「package formatを一つに統一する」のではなく、異なるpackage ecosystemやdistribution methodをbackendとして束ね、同じversion-management UXを提供する方向がある。miseはその代表例である。
miseはasdf、aqua、cargo、conda、dotnet、gem、GitHub、GitLab、Go、npm、pipx、S3等をbackendとして扱う。利用者はmise use等の共通interfaceを使うが、その下で実行されるdistribution modelはbackendごとに大きく異なる。
これはビルド済みパッケージ配布を一括りにしないの分類を「一つ選ぶ」のではなく、複数の分類をdispatcherの下へ置く設計とみなせる。
例えば同じmiseでも、
- aqua backend: registry metadataからupstream binaryを取得
- github backend: GitHub releaseを直接扱う
- cargo backend:
cargo installでsourceからbuild - conda backend: binary package solverを利用
- asdf backend: shell script pluginでinstall logicを実行
という異なるtrust、build、dependency、fallback modelを持つ。
この設計の利点はuser-facing workflowを統一できることにある。toolごとにHomebrew、npm、cargo、download script等を覚えず、version pinning、activation、PATH管理を共通化できる。
一方、同じCLI UXが同じsecurity propertyを意味しないという注意が必要になる。
mise自身もbackendごとのsecurity差を認識しており、asdf pluginをlegacyとして、新規registry entryではaqua/githubを優先している。aqua backendではchecksum、Cosign、SLSA provenance、GitHub Artifact Attestations等のverificationをnative実装している一方、asdf backendはthird-party shell pluginを実行する。これは installer scriptを許すほどpackage managerのtrust surfaceは広がる の差である。
さらにmiseのaqua backendはaqua CLIをそのまま呼ぶのではなく、aqua registry formatを独自実装し、release時のregistry snapshotをbinaryへ組み込む。したがって「backend abstraction」は単なるsubprocess wrapperとは限らず、別package managerのdistribution metadata formatをprotocolとして再利用することもある。この点は package registry metadata自体がsupply-chain trust boundaryになる と aqua Registryはupstream releaseの不統一を正規化する に繋がる。
backend abstractionには別の課題もある。backendによってversion semantics、platform support、lock behavior、install side effects、offline capabilityが違うため、上位UXを完全に均質化することはできない。例えばlatestという指定一つを取っても、GitHub release、npm dist-tag、Conda channel、asdf pluginでは解決源が異なる。
したがってmeta tool managerを評価するときは、対応tool数だけでなく、
- backend選択が明示できるか
- shorthandから実backendへのmappingを確認できるか
- backendごとのsecurity verification差を可視化しているか
- registry/backendのpinningが可能か
- backend変更で同じtool nameの意味が変わらないか
を見る必要がある。
package managerの「統一」は、artifact formatを統一する方法だけではない。mise型では、異質な配布方式を保持したままcontrol planeだけを統一するという別の設計が成立する。