GitHub shouldn't be a dependency for publishing Rust on crates.io
speckx
165 points
60 comments
June 24, 2026
Related Discussions
Found 5 related stories in 132.6ms across 11,536 title embeddings via pgvector HNSW
- GitHub and the crime against software pplanu · 208 pts · June 01, 2026 · 57% similar
- Show HN: Gitdot – a better GitHub. Open-source, written in Rust baepaul · 206 pts · June 08, 2026 · 54% similar
- The limits of Rust, or why you should probably not follow Amazon and Cloudflare randomint64 · 64 pts · May 13, 2026 · 54% similar
- We Built a Haskell Package Manager in Rust raskelll · 12 pts · April 14, 2026 · 53% similar
- GitHub is sinking herbertl · 220 pts · May 10, 2026 · 53% similar
Discussion Highlights (14 comments)
Animats
Sadly, that's probably correct. No outside single point of failure that can cancel users at will can be allowed to gatekeep open source projects.
sscaryterry
Especially not now, what if they're down? ;)
ameliaquining
See the official project issue on this: https://github.com/rust-lang/crates.io/issues/326 TL;DR: They want to fix this, it's a lot of work that no one's being paid to do, there's a roadmap with specific tasks that need doing, volunteer contributions are welcome.
righthand
Aka one of the many Rust reasons why I chose to learn C.
epage
An RFC was recently merged to unblock this: https://github.com/rust-lang/rfcs/pull/3963 The implementation on this has started. Something to keep in mind is https://blog.m-ou.se/rust-is-not-a-company/ . Rust is mostly driven by volunteers working on what they find interesting. Boring/uninteresting tasks depend on funding, a warm body to accept the funding, and a reviewer.
mikey_p
The longer I go the more I have actually come to appreciate the way Packagist works for the PHP community, there are lots of cool things it does that I wish NPM or other registries did by default, like forcing you to package from a source repository, so that you can't upload a different artifact from what you keep in source control.
jauntywundrkind
The teams support may be a bit trickier/less clear to move on, but generally: this feels like a great place where atproto / bluesky support would slot in well.
androiddrew
Welcome to Golang packaging problems. Hope you get it sorted out
vsgherzi
I agree and so does the rust project. The main problem is that it's alot of work and it's hard. https://www.youtube.com/watch?v=zGS-HqcAvA4 Here's a long video from jon gjengset that shows how it works and some of the effort already done to de-couple from github. Crates is widely used so it's a rebuilding the track while the train is driving kind of problem. It's just not a priority for the project right now, but I would also definitely like to see the issue done. It might be good for the rust project to vote on things like this during surveys so they know where to focus work!
lorecore
Go handles this well, kind of. It's super easy (in fact, transparent) to import from GitHub urls. You can self-host your Go packages, but it involves making and hosting some manifest files. Not as seamless as using GitHub, but still totally doable.
dboreham
My take: publishing Rust crates shouldn't depend on any single internet property, including crates.io.
rho138
Holy fuck it’s been a decade. Nothing is that complex.
r2vcap
From a supply-chain perspective, Cargo is still in the same broad risk category as npm and PyPI: installing packages means trusting externally published code, including code that may execute during build or installation. Rather than looking for someone to blame - in this case, GitHub - we should focus on constructive ways to harden the ecosystem.
linzhangrun
Cargo tied itself to GitHub back when GitHub still looked like an open-source utopia. Now the dependency is deeply baked in, and rolling it back would be very hard.