Open sylr opened 2 months ago
Potentially my understanding is wrong here, but I was under the impression that it's not generally advisable to commit a go.work file.
I wouldn't do it a project's root but I think it is acceptable for an examples/ sub folder.
Sorry about the delayed response on this one.
I dislike that the examples have a replace
directive in them, because it means you can't copy/paste the folder outside of the directory structure and use it, which I think is confusing when you're trying to build on top of an example.
It sounds like a go.work
file is a good way to avoid this, but also that the general idea is that they shouldn't be checked in.
I'm not an expert on Go workspaces, and don't recall using them myself. I guess they allow you to open multiple Go projects at once or something?
So, the reasons we haven't merged this seem to be that @joerdav and I don't currently have the knowledge and experience to make a call on this, so we need to do that before we can make a call on it, hence the delay.
The use case I've seen for workspaces is very different than this, like for using a local version of a dependency without editing the go.mod
And most projects I've seen have it gitignored, but if this works then maybe it's a correct use case too!
If you want an example of checked in go.work you have https://github.com/kubernetes-sigs/kustomize/.
Go workspaces are easier to override.