You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 23, 2021. It is now read-only.
After moving some shared scripts to using gobin for several project tools, a colleague of mine expressed a concern that .gobincache directories in every project might eat up a lot of disk space due to having lots of duplicate binaries for the many projects he may be working on.
I'm not sure what the reasoning for having the -m binaries cached in a per-project fashion, so it would be useful to know what that is.
Maybe it would be possible to provide some option (perhaps an environment variable) to change the cache location?
The text was updated successfully, but these errors were encountered:
The honest answer is that it was the easiest thing to do in the first instance and I haven't yet gotten around to doing anything better 😄
The correct way to do this is to have all binaries in the same cache, keyed by the hash of the transitive dependencies (following the same pattern as the cmd/go build cache).
That said, things shouldn't be too bad as it stands: each of these separate caches is trimmed (i.e. old entries are purged) when the cache is updated. The only slightly annoying thing is that there is a cache per module, which needs to be git ignored (or equivalent).
Let me retitle this issue to be the placeholder for the proper fix.
myitcv
changed the title
Should -m (go.mod) cache really be per-project?
Use a single cache for global and non-global binaries
Aug 8, 2019
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
After moving some shared scripts to using
gobin
for several project tools, a colleague of mine expressed a concern that.gobincache
directories in every project might eat up a lot of disk space due to having lots of duplicate binaries for the many projects he may be working on.I'm not sure what the reasoning for having the
-m
binaries cached in a per-project fashion, so it would be useful to know what that is.Maybe it would be possible to provide some option (perhaps an environment variable) to change the cache location?
The text was updated successfully, but these errors were encountered: