[Idea] Cargo Global Binary Cache

tools and infrastructure cargo
26

So let me try to articulate an alternative answer to that design problem. Edit: to be clear I am not speaking for the Cargo Team.

Proposal

There are two folders Cargo uses for keeping track of and building your project and its dependencies.

  1. There is one set by the environment variable CARGO_TARGET_DIR and the target-dir field in .cargo/config and defaults to /target. The exact content and structure of this folder is an implementation detail of Cargo, and can be changed in the future, but this proposal does not suggest changing it. This folder is used for artifacts that Cargo thinks will only be useful to this project. The exact rules for what goes in this folder are implementation details of Cargo, and can be changed in the future, but it will include the bin and lib and test artifacts for the project being compiled.
  2. The other one is set by the environment variable CARGO_CACHE_DIR and the cache-dir field in .cargo/config and defaults to being the same as target-dir. The exact content and structure of this folder is an implementation detail of Cargo, and can be changed in the future, but this proposal suggests starting it the same as the target-dir. Cargo will always support using the same folder for both even if the default changes in the future. This folder is used for artifacts that Cargo thinks may be useful to other projects.

Why keep the same structure between the two folders?

Cargo does a good job of rebuilding/reusing only when needed. That “fingerprint” system is coupled to the folder structure. By keeping the structure we can keep the working system. Also tools built for cleaning one will work on the other.

Why does cache-dir default to target-dir?

This means that accepting this proposal will not break any existing users. Then when this is working well it is not hard to propose changing this default to /target/cacheable/ for eazy CI cashing, or to ~/.cargo/build_cache/ for good multi project cashing. The bikeshed of what is a good default and whether it is worth braking users, is left for a follow up. Edit: This also means that if we are not caching in a way best optimized for this new use, then we are not inflicting it on the community. Unless a user opts into it, or until that follow up. User opt in gives us time to debug this before we seriously suggest that follow up. See the conversation below.

What exactly goes in the `cache-dir?

I don’t know. That is why I want it to be an implementation detail we can change. I think making it “things from crates.io” as @matklad demonstrated, or “not primary” as @haohou was working on, would be a good place to start.

1 Like