where should submodules be checked out?

[rogpeppe]

If we try to replace two modules in the same repository, the current gohack scheme
of checking out to a single global root won't work well because the two modules
may clash (for example they may well be checked out at different versions).

One possibility might be to detect when there's a clash and use a different
name for the directory that holds the VCS directory. The problem with that
is that names become unpredictable.

[bcmills]

If they're in the same root and at compatible versions (that is, if the code within that submodule hasn't changed since the requested version), I'd say leave them in the same repository (and just update replace directives appropriately).

If they're in the same root at incompatible versions, maybe emit an error?

[rogpeppe]

If they're in the same root and at compatible versions (that is, if the code within that submodule hasn't changed since the requested version), I'd say leave them in the same repository (and just update replace directives appropriately).
If they're in the same root at incompatible versions, maybe emit an error?

I'm not entirely sure whether that's a good idea. The error situation you describe will be increasingly likely the larger a program is. It would be frustrating to want to add a printf somewhere in a large program only to be told that it can't be done because of a version clash.

Note that this issue also applies when you've got multiple major versions of a repository. I think it's reasonable to want to hack on both example.com/m and example.com/m/v2 at the same time, but the current approach wouldn't allow that.

I'm currently thinking of checking out all modules to $GOHACK/module/_mod instead of just $GOHACK/module. That way this issue goes away because it's perfectly OK to have example.com/m/_mod and examples.com/m/v2/_mod.

The down side is that you might well want to use the same directory for both. There's always go mod edit --replace for that, I suppose.