[go-nuts] Re: go mod:Force dependency to use newer major version of a module?

I doubt you’ll like this answer but the one way i know we’ll work is if you fork the repository, bump the version, and then replace the dep with your fork. Joe On Monday, April 14, 2025 at 8:37:15 AM UTC-5 twp...@gmail.com wrote: > Hello, > > My project uses github.com/google/go-github/v71 and

Re: [go-nuts] How to use weak pointers?

I think it depends on your definition of cache. Caching the result of some computation that is related to the lifetime of a variable (but for any number of reasons needs to be decoupled from it) isn't necessarily a canonicalization map, but weak pointers may still be the right tool. I'm not sur

Re: [go-nuts] Inconsistency in GC behavior depending on runtime.Goexit

I dug into your example and I think I see two problems. The first problem is that `S` gets allocated in the tiny allocator, and so its lifetime may get batched together with something long-lived. This creates some inconsistent behaviors in the non-Goexit case. (I have an experimental debug mode

[go-nuts] go mod:Force dependency to use newer major version of a module?

Hello, My project uses github.com/google/go-github/v71 and one of its dependencies uses an earlier major version of the same module, github.com/google/go-github/v61. Consequently, the compiled binary contains both major versions of go-github, which bloats the binary by about 2MB. Is there a wa

Re: [go-nuts] go mod:Force dependency to use newer major version of a module?

On Mon, Apr 14, 2025 at 9:37 AM twp...@gmail.com wrote: > Hello, > > My project uses github.com/google/go-github/v71 and one of its > dependencies uses an earlier major version of the same module, > github.com/google/go-github/v61. Consequently, the compiled binary > contains both major versions