Why stdx is not on crates.io

"The solution to rust's supply chain woes is me stealing some code and vibe coding the rest" is truly one of the take of all time.

And in general, people pointing at Rust "limited" stdlib (it's only limited compared to Python) as one of the big issue and risk with rust are, in my opinion, misguided. You will never make an stdlib big enough to remove the need for external dependencies. It also creates a bunch of other problems. Actually, to take Python as an example, some functionality being in the stdlib have created a bunch of issue over the years since you can't just introduce breaking changes in an stdlib as easily. Look at urllib2/3 or xml in python. In the end, almost everyone ends up using requests and lxml instead. There are many issues that need to be dealt with to mitigate supply chain attacks. A bigger stdlib or an "stdlib-extended" a la Boost, is not one of them.

Also, specifically for Rust, many people run in a no-std environment (anything sized constraint for the most part). So another stdlib would do nothing for them.

It just looks like stdx has copied stuff from crates and put it in a git repo.

It feels like this is worse than a package manager? As in why would I trust a random git repo to keep things up to date over the officially published channel?

> stdx is a monorepo of, as of today, 64 crates

It's quite an, ahem, interesting mix of libraries, including three csv libraries, hyper_utils (but not hyper itself), and a ton of copied crates from other maintainers.

I hope the author has a good way of updating these with upstream fixes (some look out-of-date already), otherwise you may replace one security issue with another.

And the name stdx has been taken on crates.io, more than 11 years ago which can also be equally confusing.

Namespace pollution is an annoying problem in Rust. A while ago I was looking for a crate to help build something to interact with Apache Solr. Great, there's a Rust crate called `solr` on crates.io. And here it is: https://github.com/lambdastackio/solr-rust

There are other examples of crates registered on crates.io with prominent names that are just stubs with one commit from years ago. I'm sure this problem also exists for other languages but it feels worse with Rust, I suspect because of how easy it is to register a crate on crates.io combined with the "rewrite X in Rust" craze.

> Also, you can only create a crates.io account with a GitHub account

Oh is that true? They tied themselves to Microsoft it seems. What about people who won't or can't use GitHub.

Ignore this and just use `cargo-vet`, you're welcome.

stdx is on crates.io: https://crates.io/crates/stdx

But it seems to be a placeholder crate of sorts and is not Kerkour's stdx.

It does re-export several other crates, but has not been maintained or updated in a long time.

I'm a bit new to rust or npm system.

But I always thought NPM was what the author describes - just a random set of packages with git sources, which I thought was the main issue (leftpad etc.). Isn't that the case?

What about one system that just works and is there for "ages": maven repository?

Ok, I was curious enough to read look into this, but it makes no sense under the hood. The idea is essentially that:

1. Supply-chain problems affect the Rust ecosystem arguably even worse than npm. 2. `stdx` extends Rust by adding some other stuff in Go that's good for supply-chain security? 3. crates.io does stuff differently than stdx so that's why it's distributed exclusively via git.

But none of the README or article linked by the author or the other article linked in the README explain anything about what the good things from Go are that are actually added, or what the pain point precisely is compared to using crates.io. I think the first proposition is possibly correct, mainly because I know next to nothing about Rust but am all too familiar with supply-chain complaints (as are most of us by now) whether as to npm or Python ecosystems, and there is no principled reason why Rust should be more secure unless the fundamental assumption of trusting external packages to auto-update safely is somehow different in Rust. I assume without loss of generality that perhaps the author is right that Rust's package management ecosystem is no more secure as a supply-chain than Node.js's ecosystem. The second property also might be true too that Go offers some concrete solutions to the problem, though I have no idea if that's correct and wouldn't necessarily assume that to be true.

Still, even assuming all claims to be true, I do not see is any connection between those claims and actual implementation of code, aside from talk about how stdx is AI-friendly and was generated using AI. I just don't get what this does that is any different. You're still trusting a Git repository to be valid. In fact it almost sounds at one point like the author is suggesting that the whole exercise of providing proof of provenance and demonstrating that a particular version was properly published by its author is too tedious and annoying and should therefore be skipped by utilizing a simpler stdx approach to Rust (but I still don't know what that is or why I should trust it!). Is it just me? This makes no sense.

stdx is not the best example. The most popular package that is not on crates.io is probably embassy.

Also Debian tries to build and distribute independently from crates.io.

So crates.io is important but is not the (Rust) world.

More like which stdx?

I appreciate prople's efforts but they are misplaced. If I were passionate about this-- i'd do two things

1) A crates.io alternative which allows namespaces in package names like GitHub or alternatively. Single universal namespace doesn't seem fine (I don't think there would be necessarily changes required on the cargo side if users are willing to use full urls)

2) some kind of trust system so a user can up/down vote a package

3) Take a small one time payment for verifying a package? I don't know how this would work.

going where the people aren’t, a well understood strategy

I don't get it, maybe my brain isn't wrinkly enough. Two things:

1. What problem does stdx actually solve?

2. Ok, it's a git dep, seems fine? Why is the choice to publish or not publish in crates.io a big deal either way?