-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: cmd/go: enable GOCACHEPROG by default #64876
Comments
cc @bradfitz |
If this feature is not ready for non-experimental use one option would be to still require |
/cc @bcmills for thoughts |
Per the discussion in https://go.dev/cl/c/go/+/486715/14#message-086f5f820978ba6f6b2afc0589b397894afddf93, I think |
Change https://go.dev/cl/556997 mentions this issue: |
it also needs docs, and preferably importable type definition |
This proposal has been added to the active column of the proposals project |
Placed on hold. |
An item from https://go.dev/cl/556997: The cacheprog bits use "object" when other parts of the cache use "output." For example in prog.go: go/src/cmd/go/internal/cache/prog.go Lines 94 to 95 in 4a7f3ac
vs the OutputID type and its use elsewhere: go/src/cmd/go/internal/cache/cache.go Lines 32 to 33 in 4a7f3ac
It would be good to get the cacheprog path using "output" instead of "object." |
Another issue uncovered in testing: it appears that with |
It seems like maybe fuzzing's use of GOCACHE for something completely different was a mistake. Perhaps that should be rethought. |
Moving back to active now that there are pending tests. |
This proposal has been added to the active column of the proposals project |
There is #48901 that proposed a new environment variable. |
I'd really like to start experimenting more with this at Hashicorp, but having to build a custom Go toolchain is a bigger ask of our teams. I wrote a little s3-backed POC and based on my tests, it's pretty much a no-brainer. Let me know if I can help bump this along as I have a vested interest :) |
I'm trying to separate out the proposal aspect of this from the implementation aspect of this. From a proposal perspective:
From an implementation perspective, the integration tests would clearly need to land before enabling it by default. Are there any other implementation blockers to enabling GOCACHEPROG by default? |
Based on my understanding of Tailscale's and others' use, such as in this issue, I agree it seems folks are happy with the interface/protocol.
It'd probably be my preference to see the names aligned unless there is a strong reason not to. Perhaps @bradfitz can comment on intent? I am not aware of any other blockers but it has been a bit since I've looked at things. Re the tests CL: I admittedly did fizzle out on that waiting for more feedback. Happy to try and pick it up again with help. |
@bradfitz thinks "object ID" may have been a typo and he'll look into it. :) |
Have all remaining concerns about this proposal been addressed? The proposal is to enable |
Opening this so it can at least be considered for 1.23.
With #59719 and #60419 we got support for
GOCACHEPROG
in 1.21+. However, it requiresGOEXPERIMENT=gocacheprog
be set at toolchain build time. This means official Go builds don't supportGOCACHEPROG
and that can make it difficult to use.Based on issues such as dominikh/go-tools#1458 it seems at least Tailscale are having success with
GOCACHEPROG
.Should it be supported by official Go builds, removing the need for toolchain-build-time
GOEXPERIMENT=gocacheprog
?The text was updated successfully, but these errors were encountered: