Gauche:パッケージ管理

Gauche:パッケージ管理

(Shiro:2023/12/26 05:30:21 UTC) 遅きに失した感はあるけど、むしろ待ったおかげでシンプルになった面はあるかもしれん。

(元Rubyist) エンドユーザ&アマチュア開発者の目線ですが、依存関係部分も含めてパッケージ名はパッケージ名として扱われているとわかりやすいのかなと思いました。

# Bundlerが参照するGemfileの例
source "https://rubygems.org"
gemspec # Gemfile内からランタイムで必要なパッケージの情報を取得 
gem 'nokogiri'
gem 'rails', '5.0.0' # 5.0.0 指定
gem 'rack',  '>=1.0' # 1.0 以上
gem 'thin',  '~>1.1' # 1.1 以上、2.0 未満
gem 'my_gem', '1.0', :source => 'https://gems.example.com' # rubygems.org 以外からインストール

Shiro(2024/01/03 20:51:51 UTC): 記述的なパッケージ名がわかりやすい、というのは同意なんですが、 ユーザアカウント作って登録してもらう形だと、長くやると連絡が取れなくなるユーザが出てきて 片手間で運用するには面倒だな、というのが一番大きな理由です。

が、リポジトリインデックスサイトにリポジトリURLを登録したら、package.scmから自動的に リポジトリ名を引っ張ってきてインデックスを作る、というのでもいけるかもしれません。 重複があったら登録時に弾く。開発が止まって、後継がforkされて開発継続した場合、 元のpackage.scmに引き継ぎ先を明記してもらえばインデックスも更新される。 これならユーザ管理せずにパッケージ名とリポジトリを安全に管理できそう。

(元Rubyist) 参考になるかわかりませんが、R言語にはパッケージを管理しているCRANというサイトがありまして、定期的に全パッケージが自動でチェックされていて、例えばC拡張のコンパイルの際にWarningがでていると自動でメールで連絡がきて、期日(3週間程度)までに解決できないと、Archiveされてしまうという仕組みがあります (そもそも初回登録の際に人のチェックが入ってWarningやドキュメント不足があると修正を求められますが、CRANの標準gccがバージョンアップした時などに登録済みパッケージに新規でWarningが発生するときがあります)。パッケージ作者と連絡が取れなくなって困るのは、必要な修正が行われない時かなと思いましたが、ある基準をつくって対応がなければArchiveするという方法もあるという話でした。参考になりましたら幸いです。

Shiro なるほど。人手が少ないのでなるべく人間による管理の手間を避けたいというのが 一番大きいんですが、自動で回して連絡取れなくなったらフラグ立てるというのは可能性としてありますね。


昔の議論

(Shiro:2016/01/05 03:41:04 UTC) パッケージ管理機能についてのメモ。

欲しいもの: 必要なライブラリを書いとくと、依存するものまで自動的に引っ張ってきてよきにはからってくれる機能

もともとの目論見としては、dpkgやrpmのような既存のパッケージマネージャが既にそういう機能を持ってるので、重複して開発するよりそっちに乗っかる方がいいかなと思ってた。のだが、

これをライブラリ作成者にやってもらうのは難しい。

他の言語処理系を見ても、自前でやるのがトレンドっぽい。

(ポータブルなSchemeならsnowに乗っかるという手があるが、Gauche専用だと別に持つ方がよいだろう)

必要な機能:

メタデータ

できればsnowのとある程度コンパチにしたいけど、引っかかりそうなところ

メタコマンド

leinとかgoみたいに、パッケージ管理じゃなくビルドやテスト、実行までの 面倒を見るコマンドがあると、とっつきとして導入しやすい。leinみたいにひとつファイル 落として実行したら処理系のインストールや更新までやってくれる、というのも良い。

ただ、今はGaucheで何かするときにとりあえずgoshと打つ、ってことになってて この名前は結構気に入っている。goshの上に来るメタコマンドを作るとして、新たなトップレベルの 名前を導入するのが難しい。gauche-packageみたいに長い名前だと常用するのはきつい。

覚えることを減らすなら、コマンドはgoshで統一し、gosh getだの gosh packageだのサブコマンドで何かする方が最近の流れには沿ってる気がする。 これはget.scmpackage.scmを標準で用意しとけばいいだけなので 簡単にできるんだが、goshをメインコマンドにする場合、gosh自身の インストールとアップデートをどうやるか、というのが問題になる。

  1. goshを含むGauche実体のインストール、アップデートは従来どおりの方法 (untar+configure+make+make install、もしくはディストリビューションのパッケージマネージャ)で行い、パッケージ+依存性管理はgoshのサブコマンドで行う
    • 現状の延長としては一番妥当。ただし、複数のGaucheバージョンの共存と切り替えをやりたい、などと言った話はgoshコマンドの外の話になってしまうので都度「上」のレイヤに来る仕組みを作る必要がある。
  2. goshをメタコマンドに変更し、スクリプト名が与えられなかった場合にサブコマンドとしてreplを起動する。
    • leinみたいにgoshをシェルスクリプトにしておけば、「とりあえずgoshだけ落としてgosh installしてもらえばいい」ってことができるし、複数バージョンの共存と切り替えもgoshのレベルでディスパッチすれば良い
    • 一段クッションを噛ませることになるので、goshでスクリプト起動している場合のオーバヘッドが嫌。
  3. goshに現在のrepl機能とメタディスパッチ機能を両方持たせる。最初のインストールだけは別にやってもらうが、一度goshが走ったら、新しいバージョンのインストールとか複数バージョンの切り替えはgoshで行えるようにする。
    • ちょっとアクロバティックではあるけど、Gaucheの機能の本体はlibgauche.soにあるわけで、実行時にどのバージョンのDSOを使うか選択することはできる。つまり、goshと打って起動されるのはPATH上にあるgoshコマンドでそれは多分最新のものだけど、環境変数なりオプションなりでどのバージョンのlibgauche.soをロードするか決めてdlopenして制御を渡す。
    • dlopenまわりの抽象化はlibgaucheとは独立して持たないとならないのでややごちゃごちゃするけど、gosh本体はlibgauche.soに(ld.soの意味で)依存しないので自由度は増す。
    • あーでもlibgauche.soをdlopenすると、拡張モジュールはそこからさらにdlopenすることになるな。多段dlopenはOSによる差異が面倒だったような気が。

ディスカッション

More ...