パッケージマネージャを自作するときに考えること - gfnweb

プログラミング言語を自前で創っていると，パッケージマネージャが欲しくなってくるものだ．既存パッケージマネージャやそのラッパーによる配布で事足りることも多いが，自前言語の要件とうまく合わなかったりして，真に自分で実装せねばならないこともある．そうした場合，パッケージマネージャをどんな設計にすべきだろうか？ 言語固有の都合には触れずになるべく一般に考慮すべき事項を洗い出し，簡単な設計例も提示してみたい． なお，本稿はパッケージマネージャの設計に焦点を当てたものであり，効率的に依存制約を解消するアルゴリズムなど実装の詳細については解説しない．実際例えばOCamlでは 0install-solver というOPAMの裏でも使われているパッケージを利用すれば制約解消アルゴリズムそのものに踏み込まずとも制約解消処理を実装でき，（それ自体に興味があるときを除けば）必ずしもアルゴリズムを理解する必要はない

[yhara]

論点がまとまっててありがたい。

[syque]

“レジストリは1つか複数か”

[sh19910711]

"プログラミング言語を自前で創っていると，パッケージマネージャが欲しくなってくる / 0install-solver: OPAMの裏でも使われているパッケージ + 制約解消アルゴリズムそのものに踏み込まずとも制約解消処理を実装でき"

[masterq]

"OCamlでは 0install-solver というOPAMの裏でも使われているパッケージを利用すれば制約解消アルゴリズムそのものに踏み込まずとも制約解消処理を実装でき"

[baja]

世の中いろんなものを自作したい人がいるんだなぁ。すごい（小並感）。