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のサブコマンドで行う
  2. goshをメタコマンドに変更し、スクリプト名が与えられなかった場合にサブコマンドとしてreplを起動する。
  3. goshに現在のrepl機能とメタディスパッチ機能を両方持たせる。最初のインストールだけは別にやってもらうが、一度goshが走ったら、新しいバージョンのインストールとか複数バージョンの切り替えはgoshで行えるようにする。

ディスカッション


Last modified : 2024/01/04 20:40:40 UTC