The Cargo.toml file gives the answer: https://github.com/Shopify/ruby/blob/rust-yjit-upstreaming/y...

There is only a single, optional dependency which is apparently only used for testing.

My guess is that this is a tradeoff made to make it more compatible with downstream distro packaging systems like Debian and Redhat, who generally look very negatively on requirements to use external package managers like Cargo. By keeping their set of dependencies very small, removing Cargo from their build process has tons of benefits in terms of how complex it will be to compile the Ruby codebase

Both Debian and Red Hat package Cargo, and also package various Rust crates as their own native packages, and then have Rust programs use Cargo to use them.

(Okay actually I’m unsure about Red Hat, but this is how Fedora does it…)

Maybe the production release has no dependencies to download, but the dev release has some helper stuff for running tests etc?

Cargo is .. not a pleasant build tool to integrate into other build systems. If you have a project (like mainline ruby) where the dominant mode is C and you need to integrate some rust into it, you will eventually feel like it'd be a useful use of your time to bypass cargo and use the compiler directly.

Cargo is a fantastic tool, easily one of the best of its ilk, but real talk: it needs to be normalized that sometimes you don't want or need to use it. It is fit to a very specific set of tasks (mostly producing stand-alone binaries), and that set of tasks is a subset of the tasks rust as a whole is fit for.

Hilariously, years ago I did some Rust/Ruby integration, for fun, and had Ruby’s makefiles just call Cargo to build the rust code. It worked just fine.

It doesn’t work for all things in all cases, of course, but it can be workable. At work we built a build system on top of Cargo to paper over some of its deficiencies. It’s not ideal but IMHO it’s still better than dealing with rustc directly. In this case it’s easier for them since they have no external dependencies.

I mean, calling rustc isn't so bad other than managing dependencies. I don't think it's really all that much more fraught than the compilers of other complex languages (including C++) that people manage to interact with directly. But cargo is simultaneously so good at dealing with dependencies, and (for lack of a better word) parasitic in its integration with nearly every crate in existence, that the moment you want to pull something else in it gets Hard.

Where it gets real messy is if you want to go back and forth (C->rust->C or rust->C->rust where the bookends are in the same codebase). This was a thing we wanted to do at the job I just left, but we never managed to make it work in a way that wasn't very janky. This was in a very mature and large C codebase managed by cmake, where we were gradually eating parts of it with rust, though.

Yes, absolutely, the end of your first paragraph is really what I mean; you end up having to basically rebuild cargo anyway. If you have a self contained code base, it’s not like rustc is inherently bad to call directly, for sure.

Yeah. I really wish cargo had a "create a build environment" mode. It would make integrating rust into other systems a lot easier.