On Tuesday 18 June 2024 at 19:33:28 UTC+1 Marcin Romaszewicz wrote: One of your dependencies could, in turn, have a dependency on that third party project. Run "go mod graph" to see what imports what and you should be able to track it down.
I thought about that but there's no reference to anything other than the v4 version of the module. I've created a minimal project that uses v4 of the original package. And that too draws down v1 of the package in addition to v4. I've also tried with another package without any replace directive and the same thing happens. Using https://github.com/go-chi/chi as an example. I create a test program using the "as easy as" example in the README. go mod init <test_url> go clean --modcache go mod tidy Output: go: finding module for package github.com/go-chi/chi/v5/middleware go: finding module for package github.com/go-chi/chi/v5 go: downloading github.com/go-chi/chi/v5 v5.0.13 go: downloading github.com/go-chi/chi v1.5.5 go: found github.com/go-chi/chi/v5 in github.com/go-chi/chi/v5 v5.0.13 go: found github.com/go-chi/chi/v5/middleware in github.com/go-chi/chi/v5 v5.0.13 I can't really pretend to understand how modules work, but none-the-less it seems odd to me. Hopefully, someone will be able to explain it. As for the replace directive, I've always viewed it as a temporary quick fix. In your own code, you can simply replace the module import with a search and replace, but the harder part is in third party dependencies where you don't own the code. Yes. I think I'm leaning towards replacing all the import references in the code. The replace directive is nice but it probably shouldn't be treated as a permanent change. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e351d163-11f8-4402-8aa9-a03eb6f7e3f5n%40googlegroups.com.
