SATySFi向けパッケージマネージャ/ビルドシステムの理想

マシンAでビルドできたらマシンBでも問題なくビルドできる

できればハッシュ値レベルで完全に同一のビルド成果物が生成されると嬉しい

IDがランダム生成な問題は気合で解決しよう！

そのために、ある文書がどのファイルに依存しているかといった情報はできるだけプロジェクト (≒Gitリポジトリ) に保存しておきたい、というモチベがある

できれば~/.satysfiは参照したくない

システムや~配下に入ったファイルに依存してしまうと再現性がなくなる

たしか~/.satysfiを編集してた気がする

これは変更できる

同じような効果は得られているけど、プロジェクト切り替えごとに書き換えが必要そう

パッケージとして管理したいもの

フォント

ユーティリティライブラリ

クラスファイル

なぜ管理したいのか

依存関係があるから

文書→クラス→フォント/ライブラリ

たとえば、文書ファイルの横に、その依存パッケージのリストが書かれたファイルを置く

package.jsonやCargo.tomlに相当する

ダウンロードしたものはたとえば./.satysfi/dist内に突っ込む

node_modulesに相当する

Cargoってどうしてるんだろう

このディレクトリはgitignoreする

ビルド時あらゆる依存物が.satysfiをLIBROOTとするようにする

もしくは~/.satysfi/みたいなとこに入れる

グローバルで共有することで同一バージョンのパッケージがファイルシステム上で被るのを防げる

ビルド時にいい感じなパス解決が必要になりそう

パッケージレジストリ

opamに乗る

なんか困るわけではないけど嫌

OCamlとの相互運用が発生するわけでもないのにOpamに乗っかるのはどうなん？という思いとかかもしれない

前提…持続可能性のためにリソースをケチりたい

要するにS3とかは使いたくないよね

誰が金払うの？

The SATySFi Foundation作るか…

SATySFiパッケージの特徴として、配布形態はテキストが望ましい

プログラミング言語ならどれもそうかも？バイナリやバイトコードが直で落ちてくる言語ってそんななさそう

中央集権リポジトリをGitHubに用意して、そこのraw.githubusercontent.comのコミット単位ファイルURLを参照するというのはどうか

順序づいたバージョンでの指定ができないな

依存パッケージ一覧ファイルでhoge@1.6と指定するとgithubusercontentの該当URLが引けるというのはどうか

そもそも分散型にしてもよく、github:aumyf/fuga@1.5みたいな指定でも良いのか？

1パッケージ1リポジトリでバージョンはタグに対して指定する

リポジトリのtar.gzをまるっと落としてくる

どれにせよフォントファイルの配布方法が微妙になる

デカバイナリをGitHubリポジトリから直接落としたら怒られそう

リリースのアセットから落とすのはわりとセーフなイメージある

フォントパッケージの実体はttf/otfなのか、それともどっかから落としてくるスクリプトファイルなのかみたいな話もある

現状のSATySFiのフォント導入がイケてない部分がある

ttf/otfをしかるべきフォルダにシュートするだけでフォントが使えるようになってほしい

これはまじで謎

前提としてNixでビルドを行う際は~にアクセスできないしネットワークリクエストも飛ばせない

パッケージをビルドするためのコマンドがネットワークからパッケージを落としてくる場合(cargo buildとか)ひと工夫必要になる

Nix側でパッケージを落としてきてビルドコマンドを実行する環境に投げ込むことが多そう

各言語のパッケージマネージャーの依存ファイルからNixのパッケージ定義をコード生成し、その定義を使ってDLしてることが多い印象

node2nix, crate2nix, opam2nixなど

language serverとの兼ね合いもある

パッケージが解決でき、Nixでのビルドは通る状況だからといって、language serverがパッケージを発見できなければサービスを提供できず開発体験が低下する

node2nixではnode_modulesとして、プロジェクトで使うパッケージ類をまとめたNixパッケージへのsymlinkを貼ることができる

これ正直微妙

node_modulesへの書き込み権限を仮定するツールが増えてきて不変なディレクトリへの参照では対応できない

OCamlなんかではopamに乗っからずNixだけでパッケージを普通に管理してしまうこともできる

Nixpkgs(Nixの中央パッケージレジストリ)にはopamで公開されてるパッケージに対して特に自動生成などは行わず手動で書いたレシピが集積されている

SATySFiそのものはNixpkgsでは依存関係をすべてNixだけで解決してduneでビルドしている

SATySFi用パッケージマネージャーをガン無視し、Nixが自力でパッケージをセットアップしてsatysfiコマンドでビルドするだけ、というのが一番シンプル

SATySFiの公式パッケージマネージャはNixです！とかもありっちゃあり

Windows対応の道が完全に塞がれる

依存解決を作る手間がなくなる

利用者のストレージ消費がマッハになる

SATySFi用パッケージの定義をパースしてNixパッケージをコード生成するというのも全然ありかも

そういうCLIツールを作る

SATySFi用パッケージをGitHubリポジトリで中央集権的に管理して、NixパッケージがCIで自動生成されるように組んだら面白そう

Rust向けNixライブラリで、なぜかコード生成しない

どうやってるのか気になるので調べたい

その手法によっては筋良すぎとなる可能性もある