![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
伺かパッケージマネージャの考察†伺かパッケージマネージャの萌芽 http://togetter.com/li/668059 から 対象物†
パッケージマネージャの利点†
これによるツールの簡易化や自動化がすすむ。 これまでにそういう文化はなかったのでこの利点が感じられるのは主にこれから作られる・更新されるツールに限定的ではある。 問題と解決策†これまでの膨大なリソースはインデックス化されていない†まだサポートor更新がされているものは配布者や有志でやって分散作業することでなんとかなるか。 リポジトリの容量問題†パッケージマネージャの参照するリポジトリを各配布者のサイトや外部アップローダのURLのみを集めたテキストデータベースとすれば、容量の問題は最小限で防げる。 パッケージの情報は何で示すのか†パッケージ本体以外の付加的情報一般としてdescript.txt的なpackage.txtなどをつけることで示せる。 個人的には書きやすくパースしやすいYAML形式がいいな。 ライセンス問題†ライセンスに関して、とくにシェルを扱う場合、MITやらCCやらの汎用ライセンスではなく個別独自のライセンスが掲げられていることが普通である。 この解決策としては、独自ライセンスといっても普通は「仕様化されていないがよくある」ものであるはず。 よって「改変可能」や「連絡必須」等の(日本語の)フラグを「CC-BY」みたいなのと同列に扱うことである程度対応できると考える。 勝手登録†インデックス化を集合知に頼る(個人や特定チーム管理だとコストが高い)以上、登録はある程度「勝手に」行われる。 ここで作者非作者の扱いについて考察すべきである。 作者以外の登録を許す場合†デメリット
メリット
逆に作者以外の登録を許さない場合†デメリット
メリット
解決策†主に作者側の大きな利益不利益は作者の意思表示問題であり、ユーザー側の大きな利益不利益は使えるパッケージの多寡の左右である。 まずこの「作者の意思表示に反する情報配信が起こりえる」問題はDisc-2、GHOST-TOWN、うわひょ改等のサイトでも同様の問題が現在までも発生しているはず。 つまり完成品のゴーストに関してはその一定の解決をみているものであるといえる。 このパッケージマネージャはそれと同様のアプローチを、ゴーストを構成するコンポーネントを対象にしてとればいいと思われる。 まず作者は配布サイトに意思表示をすることで、性善説的に意思表示に反する登録を回避している。 一方で誤ってかそれに反して登録されてしまった場合、その登録を抹消する仕組みがその保険となっている。 つまり既存の登録系サイトと同じような管理体制を敷けば、妥当な運用が出来るのではないか。 ここで前述の容量等の問題から、リポジトリは単なるURLリストであり、既存サイトと同様にデータ本体は扱わない環境にある。よってURLリストの禁止や削除を管理すれば既存のサイトと同様の運用が出来る。 さらに加えて前述のpackage.txtを参照するという側面から、これの最優先参照先をデータ本体と同一のサイト(一般的に作者の管理下にある)にすれば、登録禁止申請など以前に作者が無意味なpackage.txtやその他の仕様を記述したpackage.txtをおくことで、自動的に意思表示できる。 これは検索エンジンに対するrobots.txtのような手軽かつ有効な役割を果たす。 なおこのようにpackage.txtの最優先参照先をデータ本体と同一のサイトとして、作者サイトにpackage.txtが存在しない場合には勝手登録のpackage.txtを集めたリポジトリを参照するようにすれば、作者以外の勝手登録を許可しつつ作者の手軽な意思表示を簡単に実現出来る。 以上から、以下の仕様を提案する。
依存関係解決に関する問題 [未解決]†依存関係をもつものをインストールする場合、基点ディレクトリがないものの扱いをどうするか。 依存関係を持つものをアンインストールする場合、依存関係にありかつ他から使われていないものを削除したい場合があるが、他から使われていないという条件の判定をどうするか。 「前のバージョン」の参照が不安定である []†上記のような構造のリポジトリである場合、同一パッケージの「古いバージョン」をユーザーが参照することが事実上非常に困難である。 package.txtリポジトリの情報であれば一応自動的に古いファイルをバックアップすることは可能であるが、アーカイブは更新されてしまうので結局意味がない。 この解決としては、パッケージリポジトリにバージョン情報も付加することによって、同名で違うアーカイブを参照できるようにすることである程度解決できる。 無論作者が古いバージョンをバックアップしない場合は不可能である。 なのでこの問題の完全な解決にはパッケージリポジトリに過去登録されたパッケージを取得し保存しておくサイトが必要である。 特定用途用のWebArchiveのようなものだが、上記で回避した容量問題、作者の意思表示問題などが浮上する形になる。 後者意思表示問題は、package.txtに追加のhistory_archive属性等を設け、拒否を指定すればそれまでの同名パッケージの全てのデータを削除する等で一応対処できる。 これはPerlのBackPANにヒントを得たものです。 実装†ネイティブアプリケーションもいいが、まあLL(軽量プログラミング言語)が楽だよね。
よってフォルダの構成が不細工になったりはするが基本的に結構いろんな言語でツール配布は実質問題ない。 いくつかのLLではEXEに固めるツールがあったりする。 必要機能†思いついた感じ ローカルリポジトリ・リモートリポジトリの別†ダウンロードしといて後で使う系の用途 一般的機能†
インストール・アンインストール・アップデート†インストールはアーカイブを単純に展開するだけでも可能なのだが、アンインストールは構成ファイルを把握しておく必要がある。 インストール時に解凍したファイルを記録するか、あるいはpackage.txtやその他にリストを書いておくことが必要となる。 またアップデート時もパッケージ名とバージョンがわからないと話にならない。 package.cacheとかみたいなのをインストールしたフォルダに作る？しかしそれは配布時には全く要らない情報なわけで…… パッケージ情報†伺か関連で唯一の似たコンセプトをもつソフト、伺かゴーストマネージャはGUIアプリケーションなのでシェルの見た目情報が出せる。 現在のところ伺かのツールは基本的に「サイトに訪れてツールをダウンロードする」というサイクルを暗黙の了解にしている。 一方でパッケージマネージャはそれを無視する動線を提供するものとなる。 結局現状パッケージマネージャは特に更新停止されたツールに対して十分な情報を与え得ない。ゆえにサイトへの参照等の情報をもつ必要がある。 検索†検索キーはパッケージ名、種別(シェルとかSAORIとか)、使用条件(ライセンス)、バージョン指定等が考えられる パッケージ管理†基本的に伺かの開発は「ゴースト制作」。 「ゴースト制作」は各ゴーストフォルダに逐一ツールが同梱されていることが前提。 つまり「あるライブラリフォルダにパッケージが集中している」Python, Perl云々のパッケージ構成よりはnode.js系の「いろんなところにパッケージがある」形式を前提とすべき。 node.jsは「'node_modules'フォルダの下にパッケージ名のフォルダがあってそこにパッケージはあるよ」という方針で、比較的単純なパッケージ管理を実現している。 しかし伺かはそういうフォルダわけを可能にしていないツールが……あったりする？ アーカイブとpackage.txtの仕様†package.txtはこんな感じ？ name: my-shiori-package version: 1.0 licenses: - MIT - Artistic-2.0 - 改変可 - 改変不可 - 改変条件付 place: /ghost/master/ YAMLで書きやすくパースし易い。
↑要議論 GUI†よくあるコマンドラインのパッケージマネージャはもちろん作るとして、GUI進出はいかにするか。 伺かの構成物全般に作用する以上、プログラマ以外への利便性も考えたい。 上記LLでGUIを構成できるのは知ってるうちで以下の通り。 node.js†node-webkitというWebブラウザベースのGUIがネイティブで作れるものがある。 HTML/CSS/JavaScriptで完全に構成できる。 Perl†
ぱっとしない Python†他色々†知らない 仕様†基本的に現在配っているアーカイブに変更の必要なく、新規に構成情報を書いたpackage.txtをおくだけで、なんとかなる、という仕組みを作りたいという方向性。 どうでもいい補足 「リポジトリにはパッケージの構成情報だけもち、アーカイブは外部から取ってくる」あたりはArch LinuxのパッケージマネージャとユーザーリポジトリであるyaourtとAUR、 「それぞれのフォルダでパッケージ管理する」とこあたりはnpmとかが参考になると思います。 用語
基本となる情報†伺かパッケージマネージャで扱われるパッケージは「パッケージ名」と「パッケージのアーカイブの場所」を最も基本的な情報として扱われる。 パッケージリストリポジトリ†「パッケージ名」と「パッケージのアーカイブの場所」を対応付けるリポジトリ。 保持するデータ†パッケージ名、パッケージの保持バージョン、パッケージのアーカイブの場所の情報を持ったYAMLである。 - name: パッケージ名 retain_version: 2.2 archive: http://www.example.com/example.2.2.zip 場所†パラメータはもたず、単一のURI( http://www.example.com/package_repository 等 )で表されるリポジトリである。 動作†参照 パッケージマネージャはまず最初にこのリポジトリを参照し、「パッケージ名」、「パッケージの保持バージョン」と「パッケージのアーカイブの場所」の対応リストを得る。 次に「パッケージのアーカイブの場所」からアーカイブリポジトリを参照する。 変更 リポジトリは可能な任意のユーザーが変更可能である。 このリポジトリには「パッケージ名」、「パッケージの保持バージョン」と「パッケージのアーカイブの場所」のみを登録可能であるべきである。 このような単純な構成のリポジトリは、CGI等のプログラムを必要とせず、単にファイルを配置するだけで構成可能である。 補足†リポジトリとしては検索機能等は提供しない。 それらは本質的でない。 パッケージマネージャ上や他の場所で提供できるし、されるべきである。 アーカイブリポジトリ†「アーカイブ」と「package.txt」をもつリポジトリ。 これは通常「アーカイブ」の作者サイトか作者が制御できるファイル置き場である。 保持するデータ†「アーカイブ」と「package.txt」が同一のディレクトリに配置されているか、「アーカイブ」のみが存在する。 「package.txt」はアーカイブ名に「.package.txt」をつけた名前「(アーカイブ名).package.txt」である。 場所†「パッケージ名」に対応した「パッケージのアーカイブの場所」に存在するリポジトリである。 動作†参照 パッケージマネージャは2番目にこのリポジトリを参照し、「package.txt」を得るか、「package.txt」が存在しないことを検知する。 正常な「package.txt」が存在する場合、「アーカイブ」がダウンロードされ、リポジトリの参照はここで終了する。 不正な「package.txt」が存在する場合、処理は失敗し、リポジトリの参照はここで終了する。 「package.txt」が存在しない場合、「パッケージ名」からpackage.txtリポジトリを参照する。 変更 通常「アーカイブ」の作者のみが情報を変更できる。 特筆すると、「アーカイブ」をパッケージマネージャから利用できなくするために不正な「package.txt」をおくことは違反ではない。 package.txtリポジトリ†「パッケージ名」と「package.txt」を対応付けるリポジトリ。 保持するデータ†「パッケージ名」に対応した「package.txt」が配置されている。 場所†「パッケージ名」をパラメータにもつ複数のURI( http://www.example.com/package_txt_repository/package_name/package.txt 等 )で表されるリポジトリである。 動作†参照 パッケージマネージャは必要な場合最後にこのリポジトリを参照し、「package.txt」を得るか、「package.txt」が存在しないことを検知し、リポジトリの参照を終了する。 正常な「package.txt」が存在する場合、アーカイブリポジトリから「アーカイブ」がダウンロードされる。 それ以外の場合、処理は失敗する。 変更 リポジトリは可能な任意のユーザーが変更可能である。 このリポジトリには「パッケージ名」と「package.txt」のみを登録可能であるべきである。 補足†リポジトリとしては検索機能等は提供しない。 それらは本質的でない。 パッケージマネージャ上や他の場所で提供できるし、されるべきである。 このような単純な構成のリポジトリは、CGI等のプログラムを必要とせず、単にファイルを配置するだけで構成可能である。 アーカイブ†通常ZIPファイルである。 ZIP以外の場合それを解凍・配置するスクリプトが必要となる。 package.txt†パッケージの情報をYAML形式で書いたファイル。 すでにUTF-8が普及しているのでUTF-8を使用する。 仕様は策定中です。変更がありえます。 name: パッケージ名
version: 1.000
type: saori
description: テストパッケージです。
tags: [テキスト処理, カット]
sites:
- name: http://www.example.com/test_package/
description: 公式サイト
readme: http://www.example.com/test_package/readme.txt
place_on: ghost
place: /ghost/master/
licenses:
- 改変可能
name†パッケージ名。 YAMLファイルに書けるあらゆるUTF-8の範囲の文字が許容される。 version†パッケージのバージョン。 ドットで区切られた数値を使用する。 (上位) 2.2.34.1 (下位) ドットで区切られた各桁ごとに直感的に上位の数値から比較される。 ゼロパディングは必要としない。下記のようなバージョンも正しく処理される。 2.0.99 -> 2.0.100 パッケージのアップデートを考慮し、新しいパッケージは常に大きい数値を使うべきである。 パーケージリストリポジトリに登録するバージョンはこれの上位桁数値である。 パッケージリストリポジトリに登録されたバージョンが2.2だった場合、package.txtによるバージョンが2.2または2.2.*でないなら不正なpackage.txtとして認識される。 特に、互換性の無いバージョンアップでは上位桁のバージョンを変え、パッケージリストリポジトリに別バージョンとしてアーカイブを登録することが推奨される。 アップデートの時にはインストール済みのパッケージとこの数値が一致する場合処理がスキップされるので、少しでも変更があった場合は必ずバージョンをあげるべきである。 type†パッケージのタイプ。 既定のタイプ文字列を指定する。 dependencies†依存関係。 依存関係にあるパッケージの名前とバージョンの情報を持った配列を指定する。 基本的に前に記述されたものから順に処理される。 nameにパッケージ名、versionに有効なバージョンを記載する。 dependencies:
- name: hoge
version: 2.2
- name: piyo
version:
min: 1.0.9
max: 1.9
バージョンは単一の値を指定するか、最大を示すmaxまたは最小を示すminを指定することができる。 パッケージリストリポジトリに対応する上位桁バージョンが無い場合失敗する。 また対象のpackage.txtのバージョンがこれに一致しない場合も失敗する。 バージョンを記載しないことも可能である。 制約内でとりうる最新のバージョンがインストールされるが、互換性の問題等も出る場合があるので上限バージョン等も適切に指定することを推奨する。 description†パッケージの簡易な説明。 任意の文字列を指定する。 tags†パッケージの内容を示すタグ。 任意の文字列を配列で指定する。 tags: - hoge - piyo 順不同に処理される。 sites†パッケージのWebサイト。 下記のようなURLと説明(省略可)を含むリストを指定する。 sites:
- url: http://example.com/
- url: http://example.com/image
description: 動作風景
複数のサイトが指定できるが、1つ目のみが代表的なサイトとして使用されることを想定して記述すべきである。 http://等の一般的なスキームのほか、アーカイブ内からのパスを示すarchive://とアーカイブリポジトリ内からのパスを示すrepository://が使える。 ただしsitesにおいてarchive://は非推奨である。 readme†パッケージのreadme。 URLを指定する。 http://等の一般的なスキームのほか、アーカイブ内からのパスを示すarchive://とアーカイブリポジトリ内からのパスを示すrepository://が使える。 changelog†パッケージのchangelog。 URLを指定する。 http://等の一般的なスキームのほか、アーカイブ内からのパスを示すarchive://とアーカイブリポジトリ内からのパスを示すrepository://が使える。 thumbnails†パッケージのイメージ。 下記のようなURLと説明(省略可)を含むリストを指定する。 thumbnails:
- url: http://example.com/thumbnail.png
- url: http://example.com/hoge.png
description: 動作風景
- url: repository://piyo.png
description: インストール時のファイル構成
複数のサムネイルが指定できるが、1枚目のみが代表的なサムネイルとして表示されることを想定して記述すべきである。 サポートされる画像形式は画像表示可能なWebブラウザが一般的に対応しているJPG,GIF,PNG,SVGとする。これ以外の画像形式(TIFF)等は表示を保証されない。 http://等の一般的なスキームのほか、アーカイブ内からのパスを示すarchive://とアーカイブリポジトリ内からのパスを示すrepository://が使える。 place_on†パッケージの配置場所の種類 既定のタイプ文字列を指定する。 place属性のルートをどこにおくかの区別をする。 'ghost'ならゴーストディレクトリのルート、'baseware'ならベースウェアのルート、これを指定しない場合カレントディレクトリとなる。 place†パッケージの配置場所。 パス文字列を指定する。 place_onで決められたルートからここで指定したディレクトリを掘って、その下にアーカイブを展開する。 reduce†パッケージアーカイブのディレクトリから先頭のディレクトリを省いて解凍する。 正整数値を指定する。 この値のレベルだけ先頭のディレクトリが削除されて解凍される。 licenses†パッケージの使用条件(ライセンス)。 要考察 インストール†インストール場所の決定†package.txtのplace_on属性=ghost ゴーストのルートディレクトリをパッケージのベースルートディレクトリとする。 そのためパッケージマネージャのカレントディレクトリから上の階層をたどってinstall.txtを含むディレクトリをベースルートディレクトリとする。 もし見つからなかった場合はカレントディレクトリをベースルートディレクトリとする。 このとき警告を出すべきである。 このベースルートディレクトリをルートとして同place属性にある位置をパッケージのルートディレクトリとする。 package.txtのplace_on属性=baseware ベースウェアのルートディレクトリをパッケージのベースルートディレクトリとする。 そのためパッケージマネージャのカレントディレクトリから上の階層をたどってinstall.txtとshellを含まずballoonを含むディレクトリをベースルートディレクトリとする。 もし見つからなかった場合はカレントディレクトリをベースルートディレクトリとする。 このとき警告を出すべきである。 このベースルートディレクトリをルートとして同place属性にある位置をパッケージのルートディレクトリとする。 package.txtのplace_on属性なし カレントディレクトリをベースルートディレクトリとする。 このベースルートディレクトリをルートとして同place属性にある位置をパッケージのルートディレクトリとする。 アーカイブ内容の配置†パッケージのルートディレクトリ以下にアーカイブを解凍する。 このときベースルートディレクトリ下の".germ.package.[パッケージ名]"にインストール情報を記録する。 この[パッケージ名]はURLエンコード([A-Za-z0-9]と[-_!~.()']を除く文字(encodeURIComponent()の回避文字から[*]を除いたもの)について)されたパッケージ名である。 インストール情報はpackage_informationキーにpackage.txtの内容、elementsキーにアーカイブから解凍したファイルのパス(パッケージのルートディレクトリからの相対パス)を記録したYAMLである。 アンインストール†インストール情報の把握†インストール情報を参照するため、package.txtのとりうる全てのplace_on('ghost', 'baseware', 空)の場合のベースルートディレクトリをパッケージマネージャのカレントディレクトリから上の階層をたどって検索する。 優先順位は'ghost', 'baseware', 空の順である。 それぞれのディレクトリでインストール情報のファイル名を探し、見つかればそれを使う。 どのディレクトリでも見つからなければ失敗する。 ファイルの削除†インストール情報を参照し、まずファイルのみを削除する。 次にディレクトリを削除するが、削除できなかったディレクトリはそのまま残す。 最後にインストール情報ファイルを削除する。 禁止仕様†インストール時のフックコードの実行は一般のパッケージマネージャではよく採用されているが、伺かパッケージマネージャの構成ファイルは人が登録制でなく信頼性が低いと考えられるので禁止する。 インストール時のリネームも同様であり、つまりパッケージはアーカイブの解凍された状態が最終状態である必要がある。 Germ (node.jsによるパッケージマネージャの実装)†注意†人柱版です。 初回版だしアンインストール時にHDDを綺麗にするようなバグがあるかもしれません(ﾈｰﾖ……たぶん 古いバージョン†package.txt等の仕様が互換性なく再策定されたので、このプログラムは旧仕様の範囲では動作しますが、今後の伺かパッケージマネージャとしては使えません。 新仕様対応版をいつか作ろうと思います。 使い方†ZIPの中にあるgerm.cmdが実行できます。 とりあえずコマンドを実行してみてください。 germ list germ search test germ info test germ install test germ remove test germ get test install/remove/search/list/info/getをとりあえず実装しました。 リポジトリはとりあえずhttp://germ.narazaka.net/に静的ファイルでおいてます。 名前†Rubyのgemと似てる（ぉ 短い名前をmateria, embryoから考えて辞書で引いたらこうなったです。。。 ライセンス†このソフトウェアにはApacheライセンスのソフトウェアrequestが使われています。 MITライセンス(http://narazaka.net/license/MIT?2014)の元で配布いたします。 書きかけ†まあそんな感じで ツッコミしてください†
|
