Open zjturner opened 1 year ago
No, a cursory glance indicates that dir
isn't supported in buck2; as usual I suspect the answer is "use a remote cache service" for those cases since it's a superset of functionality, anyway.
The docs you're linking to are actually the original buck1 docs, but in many (most?) cases do not apply at all to buck2. They're just stuffed under docs/legacy
, as the URL indicates.
Frankly, the docs/legacy
directory should, IMO, just be blown away and deleted, or at minimum not part of the built website, because then it will come up when using e.g. the search bar, and it's just misleading and confusing because most of the options not only don't apply, they don't even tell you they're invalid (after all, Starlark itself can use read_config
, so the possible values are 'open ended' in some sense.)
See also #152 and #250
You could possibly glue https://github.com/allada/turbo-cache onto buck2
via using them both as libs in your own tool if you want functionality in the same binary. It might even be worth putting something like turbo-cache
in buck2
behind a feature flag.
You could possibly glue https://github.com/allada/turbo-cache onto
buck2
via using them both as libs in your own tool if you want functionality in the same binary. It might even be worth putting something liketurbo-cache
inbuck2
behind a feature flag.
"Untested on Windows, but might work" rules it out for me. I'd like something that supports all of the same platforms that buck2 supports with the same SLA, or at the very least the same process for submitting fixes upstream. No word from the buck2 team yet, so I'll wait to draw any conclusions about the future here until they respond.
Also, turbo-cache unfortunately is only really available to use as a Bazel target, not as a Rust crate from https://crates.io — crates make integrating into buck2 a lot easier since Reindeer can generate rules for it, rather than porting the build rules or porting the codebase directly into here. Turbo cache does look pretty good though, aside from that...
I think there might be a vague plan to roll out a dir cache, but thus far it hasn't been required for anything we've done. It has some value, so I imagine eventually it will bubble its way up to the top.
In buck1 you could specify
dir = <some local path>
in your buckconfig, and it would use that as a local object cache. It doesn't seem to be doing anything in buck2, despite being documented here. Am I holding it wrong, and it's supposed to work? Or will this be coming later? Or is it not planned for buck2?