well known module config

[myitcv]

One of the more frequent comments from those moving from a GOPATH setup to modules is that they lose the ability to know where a given module dependency M is on disk. M is likely a module that they "own" / contribute to, and hence want to make changes and upstream them (frequently). The read-only module cache makes sense, and requiring a step to replace away from that remains sensible.

But I wonder whether gohack can do more to help here.

The directory $HOME/gohack is intentionally named so that it be considered a sort of throw-away area.

One of the early ideas we toyed with was "namespaced" hacks. But we settled on a sensible default for GOHACK and support for "namespaces" can be achieved by GOHACK=$HOME/mywork gohack $module.

That said, perhaps for this more common use case of "use the M on disk in its usual location" it makes sense to drive this with some sort of config.

# some sort of config for gohack such that well-known modules
# "hack" to a custom location. e.g. I might configure (a one-off operation) 
# github.com/myitcv/gobin to be in $HOME/work/gobin
#
$ gohack config github.com/myitcv/gobin $HOME/work/gobin

# Then everywhere I need to work on github.com/myitcv/gobin:
# 
$ gohack github.com/myitcv/gobin
github.com/myitcv/gobin => /home/gopher/work/gobin

Thoughts, please @rogpeppe @mvdan

[mvdan]

When you run that gohack config command, where is that setting stored?

Have you considered specifying the directory as part of the regular gohack some-module command? For example, if it were configurable via an environment variable, one could ensure that the variable is exported whenever one enters that directory via one of those cd magic wrappers.

An even crazier idea would be to piggyback off an existing file in a module. I can imagine a comment in go.mod, but that would be a setting for everyone cloning the repository, and not just the one author.

[myitcv]

When you run that gohack config command, where is that setting stored?

GOHACK/.config?

Have you considered specifying the directory as part of the regular gohack some-module command?

That's quite a verbose option, yes. Almost akin to setting the environment variable as part of the command itself, e.g. GOHACK=$HOME/mywork gohack $module. It requires me to specify the directory each time.

...via one of those cd magic wrappers.

I use such a magic wrapper, but not everyone does. This sort of thing feels like an additional bar.

An even crazier idea would be to piggyback off an existing file in a module. I can imagine a comment in go.mod, but that would be a setting for everyone cloning the repository, and not just the one author.

Yes, I think this is something that doesn't work... not least because this particular example is something that is global.

[rogpeppe]

I can definitely see the motivation for this idea. I might be tempted to put the config file at $GOHACK/config.txt because I don't see any particular reason for hiding it and it probably wants some kind of file extension.

Another possibility to consider is being able to specify a gohack location for a subtree. For example, I might want all modules under github.com/juju to go into /home/rog/src/work when gohacked.

[myitcv]

I also think there is some scope for a module-local config that overrides the global well known "default". In many respects this would be similar to how a git config setting at a branch level has higher precedence that its global equivalent.