crates.io の認証と公開における GitHub への依存

Rust のパッケージレジストリである crates.io は、現在、ユーザーがログインして Rust パッケージを公開するために GitHub アカウントを必要としています。これは GitHub へのシステム的な依存を生み出しており、批判的な立場からは、コア言語エコシステムにとっての「シャドウ・デペンデンシー（隠れた依存関係）」であるべきではないとの主張があります。

中央集権的な認証によるシステム的なリスク

crates.io は認証に GitHub を利用しているため、公式レジストリに crate を公開したいユーザーは、GitHub アカウントを維持する必要があります。この中央集権化は、Microsoft が所有する単一のホスティングプラットフォームへの依存を導入する、問題のある設計上の選択であると見なされています。

"I just think it's pretty messed up that crates[.]io still requires a GitHub account to login, therefore to publish Rust packages. GitHub shouldn't be a shadow dependency of the language ecosystem."

crates はどこにでもホストできるものであり、依存関係は認証に限定されていると主張する人もいますが、一方で、crates.io がデフォルトのレジストリであり、エコシステムのコアコンポーネントである以上、サードパーティのプラットフォームへの依存は重大な欠陥であると主張する人もいます。

GitHub からの切り離しの課題

crates.io を GitHub に結びつけていた当初の設計上の決定を覆すことは、多大な技術的負債を伴う困難なプロセスであると説明されています。この議論は、分散型エコシステムの理想と、それを維持するための限られたリソースという現実との間の緊張関係を浮き彫りにしています。

レジストリ維持におけるリソースの制約

公式レジストリの維持は、リソースが限られた取り組みです。コントリビューターによれば、その作業負荷は、ごく少数の有給のメンテナーに大きく偏っています。

"To be clear: approximately one person is paid to work on crates.io. That person has to provide (and will continue to provide) significant design and review support for that project, but ultimately, keeping the lights on has to take priority."

技術的負債と設計上の選択

認証に GitHub を利用することは、時間の経過とともに技術的負債を蓄積させた、不適切な当初の設計上の選択として特徴付けられています。これらの問題に対取り組むための進展は見られますが、この依存関係を排除することの難しさは、レジストリのコアアーキテクチャに起因するとされています。

エコシステム分散に関する代替的な視点

一部のコントリビューターは、問題は単なる認証にとどまらないと示唆しています。より広範な問題は、パッケージエコシステムのための単一の中央リポジトリという概念そのものであり、これは本質的に欠陥のあるモデルであると主張する人もいます。

"The whole idea of a single central repository is absolutely terrible. Crates should be able to depend on crates hosted anywhere."

この視点によれば、Rust エコシステムは、中央レジストリモデルから完全に脱却し、crates があらゆるプラットフォームにホストされているパッケージに依存できるようにすることで、より堅牢になるでしょう。これにより、GitHub や crates.io 自体にさえも、単一のエンティティへの依存を軽減できるからです。