I do wish more attention was paid to the ballooning disk space requirements for both.
I think Cargo is doing better, but I've yet to get a shared directory working for every build on a system. I shouldn't have to spend 2G per Rust project.
I think Cargo is doing better, but I've yet to get a shared directory working for every build on a system. I shouldn't have to spend 2G per Rust project.
Then again, maybe it's actually fairly rare that the things that make a crate build unique are all the same all that often, and the gains vs. complexities of caching just aren't worth it.
mkdir -p ~/cargo/target
export CARGO_TARGET_DIR="~/cargo/target"
That said, if it's not an option, I think it'd be reasonable for people to be able to make that choice themselves...
It predates almost all of them by at least half a decade, has a lot of hard thought knowledge but "Java is icky, Java is enterprise, bleh" and I can't even count how many mistakes Maven fixed back in 2005 I still see in pip, npm, cargo, etc in 2023.
It would have taken these package manager devs a few days of gratis and lawsuit free research on their laptops to save millions of end users years of pain.
I don't think downloading everything is a better solution.
Same here. CARGO_TARGET_DIR exists, but that means every time I change a feature in some crate and rebuild, suddenly it doesn't match the version that all my other projects want, and I need to rebuild again when I return to those. But it is the closest thing we have.
That being said, harder doesn't mean unsolvable.
The CAS that gets symlinked into vendorized directories à la pnpm is the Nix model, which is indeed an improvement that other package managers which support vendorization should incorporate.
rdfind doesn’t limit itself to library dependencies so I’d be worried about it fucking up on files I’d rather not have be hardlinked just because a copy exists (eg 2 checked out git clones where modifying the code in one suddenly starts modifying files in the other)