This is the default way of doing things in the monorepo(s) at Google.

It feels like torture until you see the benefits, and the opposite ... the tangled mess of multiple versions and giant transitive dependency chains... agony.

I would prefer to work in shops that manage their dependencies this way. It's hard to find.

I've never seen a place that does it quite like Google. Is there one? It only works if you have one product or are a giant company as it's really expensive to do.

Being able to change a dependency very deep and recompile the entire thing is just magic though. I don't know if I can ever go back from that.

It isnt the default way at Google. Just the way in some parts of Google.

It absolutely is so, or was for the 10 years I was there. I worked on Google3 (in Ads, on Google WiFi, on Fiber, and other stuff), in Chromium/Chromecast, Fiber, and on Stadia, and every single one of those repos -- all different repositories -- used vendored deps.

It's the same that we're doing for external crates in QEMU's experiments with Rust. Each new dependency is added to the build by hand.

Maven was the one the started the downfall into dependency hell. (Ant as well, but it was harder to blindly include things into it)

Kids today don't know how to do that anymore...

Yet Maven repository is still not that bloated even after 20+ years Java et al. being one of the most popular language.

Compared to Rust where my experience with protobuf lib some time ago was that there is a choice of not 1 but even 3 different libraries, one of which doesn't support services, another didn't support the syntax we had to support, and the third one was unmaintained. So out of 3 choices no single one worked.

Compared that to Maven, where you have only one official supported choice that works well and well maintained.

More time enables more consolidation.

No, there were never several unofficial libraries, one of which eventually won the popularity contest. There was always only one official. There is some barrier to add your project there, so might be that helped.

It's even more pronounced with the main Java competitor: .Net. They look at what approach won in Java ecosystem and go all in. For example there were multiple ORM tools competing, where Microsoft adopted the most popular one. So it's even easier choice there, well supported and maintained.

> Microsoft adopted the most popular one

That's still consolidation, and it also needs time.

Even in Rust crates like hashbrown or parkinglot have been basically subsumed in the standard library.

Agree, after I thought for more examples. Thanks, don't know why others downvote.

Besides consolidation point, I still think that "barrier to entry" point is still valid -- if it's more effort to even publish a library, its author is probably more committed already.

This works very well until different parts of the deps tree start pulling same Foo with slightly different flags/settings. Often for wrong reasons but sometimes for right ones, and then its new kind of “fun”. Sometimes buildsystem is there to help you but sometimes you are on your own. Native languages like C++ bring special kind of joy called ODR violations to the mix…

One nice thing about cargo is that it builds all your code together, which means you can pass a unified set of flags to everything. The feature of building everything all the time as a whole has a bunch of downsides, many which are mentioned elsewhere, but the specific problem of not being able to build dependencies the way you want isn't one.

I would absolutely do this for any non-toy project.

Alternatively, for some project it might be enough to only depend on stuff provided by Debian stable or some other LTS distro.