https://pantsbuild.org/ logo
Join Slack
Powered by
Engineers on my team want to memoize intermediate ...
# general
p
Engineers on my team want to memoize intermediate computations in a number of very expensive tests (lots of LLM calls, basically). They're using https://pypi.org/project/diskcache/ for this. Unfortunately, Pants' sandbox prevents the cache from being re-used from test invocation to invocation. Is it possible to, er, mount a file (the memoization cache) at a specific path that is shared across all sandboxes?
Or, alternatively (and more interestingly,) is it possible for pants to expose its own cache to userspace? Would be cool as it would allow remote builds to share application-level cache entries.
w
Can those be run in adhoc tooling? Those results are cached methinks?
I'm trying to recall, because I ran tests for Svelte or something, and they didn't need to be re-run, so I'm guessing they were aggressively cached
p
Oh, interesting. I'll take a look, great thought.
👍 1
b
If you're willing to, I think you can poke holes in the pants sandbox using absolute paths, e.g. put the cache in 
/tmp
and refer to that exact path (or similar)
p
using absolute paths
Ah, of course. This is probably my solution. Thanks, not sure why it didn't occur to me.
w
If the cache is generated by pants, then wouldn't the paths be different between machines? Or are they deterministic?
p
I think what Huon is suggesting is that we update our application code so that diskcache's cache is stored at 
/tmp/llm-cache
or similar.
(That cache isn't generated by pants.)
w
Ah, gotcha.
In the event you're randomly using Pants in devcontainers, the tmp folder permissions became a huge sticking point for a company I worked with. Permissions and stuff would reset themselves - however, if you're not operating in those containers, it makes sense
p
Interesting. Was this specific to 
/tmp
?
w
Blah, slack kiboshed my message. 
/tmp
and some pants caches. During some of the bring up of the container, sporadically, Pants would lose access to tmp and a few other places that were preloaded with data. I didn't dig in too much, but I didn't see anything particularly crazy. But I also hate the MS devcontainers, so 🤷 might have just been some configuration maybe?
p
That's annoying. We don't use devcontainers, but good to know in case someone proposes that we do.
When I step away from thinking about pants for a month, it's common for me to forget exactly what kind of isolation the pants sandbox provides. Yesterday my mental model presumed that the sandbox used an actual 
chroot
(probably because of the error message "Use 
--keep-sandboxes=on_failure
to preserve the process chroot for inspection"), which caused me to subconsciously rule out the absolute path solution.
I still do think it would be... interesting? if pants had an API that allowed you to write / read / delete from the pants cache (in a separate namespace from pants' internal entities.) It would be useful because it would allow application code to memoize computations in a way that distributes automatically when a company hooks pants up to a remote cache. (The alternative would require making a network cache available in CI, which is obviously possible and maybe a better idea for other reasons.) But this is a not-even-half-baked idea, really just spitballing. It definitely smells like a gross hack. IDK.
b
yeah, it's definitely interesting! The 
shell_command
target exposes so-called "named caches" as https://www.pantsbuild.org/stable/reference/targets/shell_command#experimental_named_caches
(Others do not, yet, but could, I imagine)
7 Views
Open in Slack
PreviousNext
Powered by