pkgxはrelocatableなversioned POSIX prefixを配る
pkgxは、Nixのstore path固定ともCondaのinstall-time prefix rewritingとも少し違う方向から、ビルド済みpackageのportabilityを扱う。pkgxのpackageは任意の場所へ移動できるrelocatableな独立POSIX prefixであることを要求される。
ビルド済みバイナリのrelocationには複数の解法がある で扱ったrelocation戦略の一つとして見ると分かりやすい。
pkgxのFAQでは、すべてのpackageはどのlocationからでも動作しなければならず、これを明示的に“relocatable”と呼んでいる。通常は~/.pkgx/<fully-qualified-package-name>/v<version>のようなversioned directoryへ展開されるが、~/.pkgx全体を別のapplicationへbundleできるとしている。
例えば一つのversion directoryは独立したPOSIX prefixになり、bin、lib、include等を持つ。pkgxは必要なpackage群からPATH、LIBRARY_PATH、PKG_CONFIG_PATH等のenvironmentを組み立て、その環境内でcommandを実行する。つまりsystem-wideな/usrへmergeするより、versioned prefixのcompositionによってexecution environmentを作る。
この設計はNixに似て見える部分もある。両者とも複数versionを独立directoryへ置き、dependencyをenvironment/pathでcomposeできる。しかし重要な違いがある。
Nixは/nix/store/<hash>-nameというstore namespace自体をdependency identityへ強く組み込み、そのpathの安定性によって任意prefixへのrelocationを避ける。pkgxは逆にpackageをrelocatableに作り、prefixそのものを移動可能にする。
CondaやSpackとの違いもある。ビルド済みバイナリのrelocationには複数の解法がある のConda/Spackはbuild prefixをplaceholderやbinary rewriteでinstall時に新しいprefixへ合わせる仕組みを持つ。pkgxはpackage側に最初からlocation-independentであることを求めるため、relocation capabilityをpackage acceptance criterionに近い位置へ置いている。
その代わりpackaging costは高くなる。upstream softwareがabsolute pathを埋め込む場合、packagerはそれを修正し、relocatableにする必要がある。pkgxのPantry documentationも「packages must be relocatable」をpackaging requirementとしている。
配布面ではdist.pkgx.devがsource mirrorとplatform/architecture別の“bottles”を提供し、version list、archive、signature/checksumを配る。目的versionが存在しない場合、FAQはticketを出してbuildしてもらうよう案内しており、prebuiltがないときのsource build fallbackは同じ意味ではない のNixのようにclient自身が同じrecipeから自動buildするモデルではない。
pkgx自身はdocumentationで「package managerではない」と表現し、package environmentを作ってcommandを実行するcomposable primitiveと位置付けている。pkgmなど別toolがsystem installを担当する。この点は miseは異なる配布モデルをbackendで同じUXに重ねる と同様に、package storage/distributionとuser-facing package-management operationを分離する例でもある。
pkgx型から得られる設計上の問いは、relocationをinstallerの責任にするか、固定store namespaceで避けるか、package producer側の要件にするかである。