Go module dependency debugging workflow

[gonutz]

What version of Go are you using (go version)?

go version go1.16.2 windows/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

The scenario: I am creating module mp3player, my main program. It uses library module mp3. While debugging I insert print statements in my main program. They show. Now I need to go deeper and want to insert a print statement in the library code. How do I do that?

I found that the code that is actually compiled is the copy of the library with the version specified by my go.mod file in the go mod cache (GOPATH/pkg/mod). The file tree in the mod cache is read-only (for good reasons) so while changing it works, it is not the way to go.

I could create a local commit to the library or create a new debug branch in my local copy of the library. Then I insert my debug code and commit it. Then I point my main program's go.mod file at the new commit/branch, adding a replace along the way to use my local copy. Then when I am done debugging I roll everything back. This works but is very annoying for just a temporary print statement here and there.

I also tried temporarily vendoring my main program but then it would not build at all. Concretely I use GLFW which contains C files but they are not copied over by go mod vendor so the library does not compile anymore. Then even if vendoring would work correctly, I still consider this too much work for debugging.

What did you expect to see?

A simple way to locally debug my dependencies without changing file access rights, using git or vendoring. In GOPATH mode this was the default behavior and made things simple while debugging. Of course I see the benefits of Go modules and want to use them but this common use case seems hard to do now.

What did you see instead?

Go modules seemingly complicating the debugging process.

[seankhliao]

Take a look at replace

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

[gonutz]

replace does not achieve this as it still specifies a commit hash. As I said, I do not want to commit my debug code.

My Stackoverflow question for this has been closed, three people said it was opinion-based. I started a new conversation on golang-nuts, thanks for pointing me at it.

Still I would consider this a bug in the sense that I was able to do what I asked in the last Go version but Go 1.16 defaults to module mode and GOPATH mode is about to be removed completely so I am not able to achieve what I want anymore. Seems to me like a flaw in the design of modules or maybe a lack of a feature for supporting this in which case we could make this issue a proposal?

[seankhliao]

replace can point to local paths
or you can make temporary edits to the code in the vendor directory after go mod vendor, these will be lost next time you run go mod vendor

[gonutz]

Yes sure, replace can point to a local path but that workflow is too cumbersome for my taste. Not only do I need to temporarily change my go.mod file and revert it later, I also have to commit the temporary debugging changes to that library because replace still requires the go.mod file to have a version or commit hash, otherwise my local changes are not used.

go mod vendor could work but as I said it is broken somehow (this might be a separate issue or an issue for it might already exist, I will have to check that) but the ref says Local changes should not be made to vendored packages. and of course this is still very cumbersome. The need to vendor just to debug is already a pain point for me.

[ZekeLu]

I also have to commit the temporary debugging changes to that library because replace still requires the go.mod file to have a version or commit hash, otherwise my local changes are not used.

That's not true. According to the doc

If the path on the right side of the arrow is an absolute or relative path (beginning with ./ or ../), it is interpreted as the local file path to the replacement module root directory, which must contain a go.mod file. The replacement version must be omitted in this case.

[gonutz]

@ZekeLu You are right! I must have had a bug in my workflow. I was sure that the changes after replacing the dependency had no effect. Now that I tried it on a fresh example module it works.

Modules are hard andl confusing.