4 ms·

Ok, maybe you can help me figure something out that I haven’t been able to. I’ve got a project broken down into modules. Module A uses module B. These are both

Ok, maybe you can help me figure something out that I haven’t been able to. I’ve got a project broken down into modules. Module A uses module B. These are both checked into GitHub, so the module path is something like guthub.com/distortedsignal/my-project/src/a or whatever. I need to make a change across both of these modules. Will my compilation pick up the changes? What if I need to make a backward-incompatible change in b when b is a fully separate project?

Groxx 3y ago
>I need to make a change across both of these modules. Will my compilation pick up the changes? Yes, add a replace directive to A's go.mod and point it to B's directory. It'll pick up changes immediately. You can also vendor + disable modules + change stuff in the vendor folder to quickly experiment, though IDEs tend to get moody about this. Backwards incompatible in principle: release a new major version of B. Import and use that. Backwards incompatible in practice: few projects actually do that reliably, IMO because tooling to help you do this or detect the need is somewhere between "bad" and "horrifyingly bad". Most just make the breaking change, increase the minimum version in A, and it'll work for anyone who stays up to date on A (this is often good enough for internal use). Though people updating B separately by hand might break.
- distortedsignal 3y ago
  Ok, I wasn’t able to figure that out when I was in the codebase. What do you do if you’re working in a fork of the project and you need to make those changes?
  - Groxx 3y ago
    Should be the same. You can replace to any location, and with modules it doesn't even need to follow GOPATH naming conventions. E.g. clone A and fork-B into adjacent folders regardless of fork status or import paths, and change A/go.mod to include replace original.com/B ../B and that should work fine. With GOPATH you would need to clone the fork into the original path. Which you can do if needed / modules don't prevent that either, but modules don't need any specific locations at all. --- The official module doc is... huge and doesn't spell things out in an easily-usable form, so you're far from alone in your confusion, but I do think it's worth reading. I routinely find people spending way more time struggling with them than it would take to read the spec and become an expert on it: https://go.dev/ref/mod https://go.dev/ref/mod
    - distortedsignal 3y ago
      Wow. You’re right - that is simpler than I expected. Thank you!
- kubanczyk 3y ago
  > Yes, add a replace directive to A's go.mod and point it to B's directory. It'll pick up changes immediately. Nowadays you just create a go.work file. That's much less cumbersome than 'replace' directives. If a module is in the go.work it isn't downloaded from a remote git repo, but overshadowed by your local files.
  - Groxx 3y ago
    Ehhh... I find it far more similar than not in terms of effort/maintenance, and much less likely to work with [random tool X] tbh. Replaces work with basically everything, and you can vendor when they don't - workspaces have no vendor equivalent AFAIK. go.work is also rough to use with existing folders / a gopath-like setup, because they're super awkward if you don't have a dedicated folder with dedicated clones with just the stuff you're using in the workspace (which has some nice benefits, but most people are not even aware you can do that afaict, GOPATH caused so much pain that there's now mental scar tissue that'll take a while to clear). Replaces work fine with that if you open two editor instances, workspaces generally index everything or nothing and get confused. Tooling support has likely improved since I last tried it (around 1.19?), and I 100% agree that it's a viable option worth considering (thanks for the comment!), but I'm not sold on them yet. Better for some things, worse for others.

Groxx 3y ago

>I need to make a change across both of these modules. Will my compilation pick up the changes? Yes, add a replace directive to A's go.mod and point it to B's directory. It'll pick up changes immediately. You can also vendor + disable modules + change stuff in the vendor folder to quickly experiment, though IDEs tend to get moody about this. Backwards incompatible in principle: release a new major version of B. Import and use that. Backwards incompatible in practice: few projects actually do that reliably, IMO because tooling to help you do this or detect the need is somewhere between "bad" and "horrifyingly bad". Most just make the breaking change, increase the minimum version in A, and it'll work for anyone who stays up to date on A (this is often good enough for internal use). Though people updating B separately by hand might break.

distortedsignal 3y ago
Ok, I wasn’t able to figure that out when I was in the codebase. What do you do if you’re working in a fork of the project and you need to make those changes?
- Groxx 3y ago
  Should be the same. You can replace to any location, and with modules it doesn't even need to follow GOPATH naming conventions. E.g. clone A and fork-B into adjacent folders regardless of fork status or import paths, and change A/go.mod to include replace original.com/B ../B and that should work fine. With GOPATH you would need to clone the fork into the original path. Which you can do if needed / modules don't prevent that either, but modules don't need any specific locations at all. --- The official module doc is... huge and doesn't spell things out in an easily-usable form, so you're far from alone in your confusion, but I do think it's worth reading. I routinely find people spending way more time struggling with them than it would take to read the spec and become an expert on it: https://go.dev/ref/mod https://go.dev/ref/mod
  - distortedsignal 3y ago
    Wow. You’re right - that is simpler than I expected. Thank you!
kubanczyk 3y ago
> Yes, add a replace directive to A's go.mod and point it to B's directory. It'll pick up changes immediately. Nowadays you just create a go.work file. That's much less cumbersome than 'replace' directives. If a module is in the go.work it isn't downloaded from a remote git repo, but overshadowed by your local files.
- Groxx 3y ago
  Ehhh... I find it far more similar than not in terms of effort/maintenance, and much less likely to work with [random tool X] tbh. Replaces work with basically everything, and you can vendor when they don't - workspaces have no vendor equivalent AFAIK. go.work is also rough to use with existing folders / a gopath-like setup, because they're super awkward if you don't have a dedicated folder with dedicated clones with just the stuff you're using in the workspace (which has some nice benefits, but most people are not even aware you can do that afaict, GOPATH caused so much pain that there's now mental scar tissue that'll take a while to clear). Replaces work fine with that if you open two editor instances, workspaces generally index everything or nothing and get confused. Tooling support has likely improved since I last tried it (around 1.19?), and I 100% agree that it's a viable option worth considering (thanks for the comment!), but I'm not sold on them yet. Better for some things, worse for others.