I would argue that for most projects (for most of my projects, anyway), this is still a sensible default. Except you should probably still be using distro packa

I would argue that for most projects (for most of my projects, anyway), this is still a sensible default. Except you should probably still be using distro packages for major libraries too. Consider; the reason for installing dependencies locally to your project is that it allows you to be precise about what library version you want. For example in Rust, we have Cargo.toml and I can have dependencies like primal = "0.2". I hate this model. It takes us right back to the old days of projects shipping whatever version of a library they want and never updating it. For small projects this is a constant source of security issues and code stagnation. I groan internally every time I see a project I'm interested in is written in node. Not because I dislike the language, but because I know when I download and build it there are going to be a dozen outdated dependencies hardcoded in the config file, some with "severe" security warnings flagged by npm. I advocate letting library developers and distribution maintainers do their jobs. Most of the time new versions of libraries are supposed to be backwards compatible. When they're not the distribution can ship multiple versions of a library and make sure they all have security updates backported. There are cases where managing all your own dependencies is important (like closed source web applications), but I think those are exceptions. Dependencies were supposed to be a solved problem.