Follow on to #27824 go.mod Using environment variable for replacement

[spekary]

This is a follow up to #27824 which was recently closed.

I have been working with JetBrains support on GoLand to see what could be done about a use case that I am dealing with and that I think is going to be pretty common as more open source projects support modules.

Here is the basic scenario. There are two open source library projects on github. Each has its own go.mod file. One depends on the other.

Project A
Project B

Project A's go.mod file points to project B.

I also have a local project that is using both of these projects. We will call it Local.

So Local's go.mod file points to both A and B.

Now, I notice some bugs or improvements I want to make to both project A and B, so I check out both of these projects, and use replace directives in Local's go.mod file to point to these. Local's go.mod file now points to local copies of A and B. Once I make my changes, I am going to build Local and make sure everything is fine.

Using GoLand, I navigate to project B and make some changes, like I add a new function called BFunc, then I navigate to project A and add AFunc, and try to call BFunc from there. When I type in BFunc, it is red and GoLand reports that it cannot resolve the name.

The reason is that when I navigate to project A, GoLand looks at A's go.mod file to find B, instead of looking at Local's go.mod file, which is where I intend to build from.

I can work around this now by changing project A's go.mod file to have the same replace directives as the Local go.mod file, but I have to be very careful not to check that change in.

This is not easy for an IDE to resolve. Somehow a developer will need to tell an IDE what go.mod file the developer intends to use for a build, so that the correct replace directives can be used to find the correct versions of all of the sources so that the IDE can then do its syntax checking and code completion magic. GoLand lets you specify a build, so they could do this based on what build configuration is currently selected, but it could get confusing, since changing the build configuration to a unit test (in project B for example) would change which go.mod file is being used at the moment, and going back to editing other code without also changing the build configuration would cause symbols to not resolve and it might not be obvious to a developer why. It also might mean that changing the build configuration would require the IDE to re-index the entire project, which can take some time.

An environment variable for replacements could potentially resolve this. It would prevent an IDE from having to worry about the go.mod file changing simply based on the navigation of the developer. Either way I think IDE's and developers are going to need some help juggling multiple projects.

[myitcv]

@spekary is there something specific about #27824 that requires a follow up here?

The use case above seems to be covered by #27824 (comment), specifically the link to #26640

[bcmills]

I notice some bugs or improvements I want to make to both project A and B, so I check out both of these projects

That general use-case is #27542. (See also @rogpeppe's gohack tool.)

I can work around this now by changing project A's go.mod file to have the same replace directives as the Local go.mod file, but I have to be very careful not to check that change in.

#26640 proposes to allow a separate file for local replacements and exclusions.

Somehow a developer will need to tell an IDE what go.mod file the developer intends to use for a build, so that the correct replace directives can be used to find the correct versions of all of the sources so that the IDE can then do its syntax checking and code completion magic.

Yes, that's true. (@myitcv calls that the “workspace”, if I recall correctly.) In general that should be the working directory in which the IDE or project was opened.

[bcmills]

changing the build configuration to a unit test (in project B for example) would change which go.mod file is being used at the moment

Yes, and if we used environment substitutions, changing the environment would also change the effective module definitions. Fundamentally you're talking about making the build system rely on the environment (rather than the code) to specify which versions to use. That's what we had with GOPATH, and part of what we're trying to avoid with modules.

[bcmills]

Closing as a duplicate of #27542. It seems clear that we will need to address the use-case of editing multiple modules, but that should not require permanent replace directives in every go.mod file — let alone replace directives whose meaning depends on the environment.

[spekary]

I will continue at #27542