様々なパッケージマネージャの比較
Kozo Nishida| conda | 名前は特に無い? (Go) | apt | pip | 名前は特に無い? (R) | cargo (Rust) | Pkg.jl (Julia) | npm (nodejs) | gem (Ruby) | bundler (Ruby) | maven (Java) | 乱立 (vimscript) | package.el(elisp) | Nix | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| このpackage managerを用いないと installが難しい(できない)重要なパッケージ |
jupyterlab | 無い (パッケージマネージャを使わなくても バイナリパッケージの配布が優秀なので?) |
blasに代表される lib**-dev系の共有ライブラリ |
condaで配布されていないPython package | tidyverse | ? | ? | typescript? | ruby on rails? | ← | ? | 何でも | ||
| 共有ライブラリの提供方法 | 依存conda packageとして提供 | packageに同梱 | 依存apt packageとして提供 | pipのwheel内に同梱 (ただし完全ではない？) |
下がyesのものは同梱? noのものは自分でローカルに セットアップする必要がある |
? | ? | ? | Windowsのfat-gem以外はno? | ← | 依存maven package として提供 |
共有ライブラリのバージョンも完 | ||
| バイナリパッケージが配布されているか (==ユーザ側コンパイルが不要か) |
yes | yes | yes | yes | WindowsとMacはyes, Linuxはno (ただLinuxでもyesにできる技術がある?) |
? | ある ユグドラシルとかいったかな |
? | ほとんどの場合no 作者が用意すればyes (fat-gemと呼ばれる。 ただし かなりマイナー) |
← | yes | yes | ||
| プログラミング 言語限定的か |
no | yes | no but C++にパッケージマネージャが無い のでLinuxのC++の実質的な パッケージマネージャがこいつと言えるか |
yes | yes | yes | yes | yes | yes | ← | yes(ScalaやKotlin等を含む) | yes | yes | no |
| 中央集権的なパッケージレポ(セントラルレポ) | anaconda公式 | 無い? debとかをつくってgithub releaseが多い？ |
ubuntu公式 | pypi | cran | crates.io | ? | npm公式 | rubygems.org | ← | ? | 無い | ? | Hydra(Nix公式) |
| セントラルレポへの自パッケージの追加(願) にレビュープロセスがあるか |
yes | no | yes | no | yes | no? | ? | no? | no | ← | no? | yes | ||
| その他のパッケージ配布レポ | チャンネルという語が用いられている conda-forge、bioconda、野良レポ? |
? | nvidia, cran, ppa など | パッケージファイルが置けるとこどこでも | bioconductor | ? | ? | ? | conda-forge | ← | ? | NUR, GitHub | ||
| デプロイ方法 | 自分でデプロイは基本的にしない | github releasesとかに deb,exeとかのバイナリパッケージを置く? |
自分でデプロイは基本しない? | 自分でデプロイする。 大体の人が twine upload mypackage で デプロイする。手作業でも可能だったかも。 |
cranの場合は自分でデプロイだったかな? | cargo ??? | ? | ? | ライブラリのリリースは gem push、アプリケーションの依存性管理は bundler で行う | デプロイ先で bundle install | ? | githubが そのままdeploy先 |
? | CIで |
| ドキュメントの生成方法 | 特にきまってない、というか元の プロジェクトがこのプログラミング言語 と決まってない |
godoc? | condaと同じ | docstring | Roxygen2, knittr, RMarkdownなど複数の パッケージを使ってAPIだけでなく実用例 ドキュメントの提供をほぼ「強制(矯正)」 する。(これは褒めて言ってます。) |
cargo doc | ? | ? | rdoc, ri (組み込み) yard (サードパーティ) |
← | javadoc生成 だけがほとんど？ |
vimdocだったっけ? | 特にない | docbook |
| プロジェクト毎にパッケージの管理が可能か | conda create env | go.modをプロジェクト毎に置く方式 | no | pipではないけど他のツール使って可能 | たぶんできる。 そのためのR package名忘却 |
Cargo.tomlをプロジェクト毎に置く方式 | ? | できる JSくわしくないが |
bundler で行う | yes ただしひとつのプロジェクト内に同一ライブラリの複数バージョンを要求するライブラリは共存できない |
? | ? | ? | yes |
| 依存しているパッケージを固定することが可能か | environment.ymlを使う | go.mod及びgo.sumにバージョンが書き込まれる Goのバージョンによって方法が違うが大体自動 |
no | requirements.txtを使う ただ完璧とは言えない感じ |
? | Cargo.tomlにバージョンを指定可能 | ? | package-lock.jsonにより指定される 自動生成だったはず |
bundler で行う ただし直接の依存パッケージだけならバージョンを指定できる |
yes | ? | プラグインマネージャーによっては固定する機能がある | ? | libcまで固定しようね！ |
| Clear |
Kozo NishidaGo、Rust、Juliaのパッケージのポータビリティとかわかってなくて気になってます。
JavaScriptも結構気になってます。
Kozo Nishida基本データサイエンス的なものに偏ってます。
が他のものも興味あります。C#とかJVM言語とか。
ただ右に長いと見れないんでシートはテーマ毎に分けた方がいいかもなと思ってきてます
Kozo Nishida当方 conda, pip, Rはまあまあ経験あると思います。
それらについて何か教えて、などあれば気楽に投稿してください。
Kozo Nishida共有ライブラリが何かについては
共有ライブラリを使うのを止めてほしいをご参照ください。
tanaka_733興味あるとのことですので、C# (.NET Core, .NET Framework) についてコメントさせてください。
|名前|NuGet|
| ---- | ---- | ---- |
|このpackage managerを用いないとinstallが難しい|No (利用しないと管理が面倒になるが追加自体はなくても簡単)|
|共有ライブラリの提供方法|ライブラリ自体はバイナリファイル（DLL）としてパッケージマネージャーに依存せず追加可能。NuGet利用時はNuGetパッケージとして提供（DLL同梱|
|バイナリパッケージが配布されているか| yes。NuGetパッケージではプラットフォーム（OS）非依存のバイナリとプラットフォーム固有のバイナリをセットで提供可能。|
|プログラミング言語限定的か|言語(C#)には依存しないが、.NET前提。|
|中央集権的なパッケージレポ|NuGet.org|
|セントラルレポへの自パッケージの追加(願)にレビュープロセスがあるか|no|
|その他のパッケージ配布レポ|誰でも構築できるNuGetサーバーにより配布可能。SaaS形式のものもあれば、共有ファイルシステム（NFS
（NFS的なもの）のみでも構築可能。|
|デプロイ方法|.NET CLIやNuGet CLIなど。|
|ドキュメントの生成方法|NuGetパッケージの設定ファイル、もしくはNuGetサーバーによってはWeb上で編集可能。|
|プロジェクト毎にパッケージの管理が可能か|yes|
|依存しているパッケージを固定することが可能か|yes|
Kozo Nishida情報ありがとうございます！
ちなみに .NET には dotnet tool というpackage管理コマンドがあるようですね。
C#と合わせて学習しようと思います！
Kozo Nishida表が見にくい気がしてきたので、各パッケージマネージャをmarkdownのheader毎に分けて文で説明する記事へと移行しようと思います。