Kyle L
Kyle L
While I'm not sure how it works, or if it will work long-term, I have a work-around at least for me in https://github.com/bazel-contrib/rules_go/issues/4286#issuecomment-2692334131.
Got it, makes sense. I will use the Java objects for now.
I've switched off Kotlin, closing.
https://github.com/VirtuslabRnD/pulumi-kotlin/issues/706 is a good example of needing to fallback to the Java bindings, and wanting to re-use my existing Kotlin logic.
Definitely possible that I am missing something better, but in the other example I have: * a Kubernetes (Kotlin) provider * I use it with Kotlin-generated bindings, works fine. *...
Sounds good, no rush though, I'm unblocked. And I empathize with the desire to both hide implementation details and also the occasional need for escape hatches. 😅
I've switched off Kotlin, closing.
Further investigation - I have another development machine that does not have the problem (It uses gopls v0.18.1, the latest at the current time) - so it seems like that...
I'm not familiar with the gocache, but it seems like only rules_go has it in external: ``` find bazel-bin/external/ -type d -name "gocache" Output: bazel-bin/external/rules_go+/stdlib_/gocache ```
More investigation rambling: I see the [GoStdLib provider](https://github.com/bazel-contrib/rules_go/blob/10b45b29fc0c52eefb68d9d0392f79dcd3d7cbc5/go/providers.rst#gostdlib) outputs the cache_dir. And that it can be a pre-compiled library from GoSDK or compiled separately (possibly one machine is doing one,...