crates.ioへのRustライブラリ公開で、GitHub依存を強制するのはやめるべき

現在、crates.ioでRustライブラリを公開するプロセスにおいて、実質的にGitHubへの依存が求められている現状があります。しかし、特定のプラットフォームに縛られるべきではなく、分散化されたオープンソースのエコシステムを目指すのであれば、GitHub以外の環境からでもシームレスに公開できる仕組みを検討すべきではないでしょうか。

残念だけど、たぶんその通りだろうね。オープンソースプロジェクトを制限するような、特定の単一障害点（SPOF）を勝手に排除できる存在なんて認めちゃいけないんだよ。

今の時期なら特にそうだよね。もし相手がダウンしてたらどうするのさ？ ;)

この件に関する公式プロジェクトのイシューを見てみて：https://github.com/rust-lang/crates.io/issues/326

要するに：彼らも修正したいと思ってるけど、誰にも報酬が支払われない膨大な作業が必要なんだ。ロードマップにはやるべきタスクが具体的に示されてるから、ボランティアの貢献は大歓迎だよ。

最近、この問題を解決するためのRFCがマージされたよ：https://github.com/rust-lang/rfcs/pull/3963

実装作業も始まってる。あと、これについては頭に入れておいて：https://blog.m-ou.se/rust-is-not-a-company/
Rustは基本的に、ボランティアが面白いと思ったことに取り組むことで動いている。退屈で面白くないタスクは、資金と、それを受け取るための体制、それにレビューア次第ってことさ。

長くやればやるほど、PHPコミュニティのPackagistの仕組みがよくできていると実感するよ。NPMや他のレジストリでもデフォルトでやってほしいと思えるクールな機能がたくさんあるんだ。例えば、ソースリポジトリからパッケージ化を強制するとか。おかげでソース管理しているものとは別物のアートファクトをアップロードできなくなっている。

同意するし、Rustプロジェクト側も同じ考えだよ。主な問題は、それがすごく大変で困難な作業だということさ。

https://www.youtube.com/watch?v=zGS-HqcAvA4
Jon Gjengsetの長いビデオだけど、仕組みとGitHubを切り離すためにどれだけの努力が既に行われているかが分かるよ。

Cratesは広く使われてるから、走行中の列車の下で線路を敷き替えるような難しさがあるんだ。

今はプロジェクトの優先順位としては高くないけど、自分もこのイシューが完了するところをぜひ見たい。Rustプロジェクトとしても、アンケート等でこうした優先事項に投票できるようにして、どこに力を入れるべきか把握できるようにするといいかもね！

Goはある意味でこのあたりをうまくやってるね。GitHubのURLからインポートするのはすごく簡単（というか透過的）だよ。Goパッケージを自分でホストすることもできるけど、マニフェストファイルを作って公開する必要がある。GitHubを使うほどシームレスではないけど、十分に現実的だ。

俺の考え：Rustのクレート公開は、crates.ioを含む特定のインターネット上のプラットフォームに依存すべきじゃない。

マジかよ、もう10年も経ってるのか。そんなに複雑なことじゃないはずだろ。

サプライチェーンの観点で見れば、CargoもnpmやPyPIと同じようなリスクカテゴリーにある。パッケージをインストールするということは、ビルド中やインストール中に実行される可能性のあるコードを含め、外部で公開されたコードを信頼するってことだからね。

GitHubという「犯人」を探すんじゃなくて、エコシステムを強化するための建設的な方法に注力すべきだと思うよ。