Use go workspaces to simplify intermodule deps

[jpkrohling]

I was able to positively confirm that all modules had some effect when added to the go.work. For instance:

$ make install-tools
cd ./internal/tools && go install github.com/client9/misspell/cmd/misspell
cd ./internal/tools && go install github.com/golangci/golangci-lint/cmd/golangci-lint
no required module provides package github.com/golangci/golangci-lint/cmd/golangci-lint; to add it:
        go get github.com/golangci/golangci-lint/cmd/golangci-lint
make: *** [Makefile:130: install-tools] Error 1

$ go work use internal/tools/

$ make install-tools
cd ./internal/tools && go install github.com/client9/misspell/cmd/misspell
cd ./internal/tools && go install github.com/golangci/golangci-lint/cmd/golangci-lint
cd ./internal/tools && go install github.com/google/addlicense
cd ./internal/tools && go install github.com/ory/go-acc
cd ./internal/tools && go install github.com/pavius/impi/cmd/impi
cd ./internal/tools && go install github.com/tcnksm/ghr
cd ./internal/tools && go install github.com/wadey/gocovmerge
cd ./internal/tools && go install go.opentelemetry.io/build-tools/checkdoc
cd ./internal/tools && go install go.opentelemetry.io/build-tools/semconvgen
cd ./internal/tools && go install golang.org/x/exp/cmd/apidiff
cd ./internal/tools && go install golang.org/x/tools/cmd/goimports
cd ./internal/tools && go install github.com/jcchavezs/porto/cmd/porto
cd ./internal/tools && go install go.opentelemetry.io/build-tools/multimod

Fixes #5991

Signed-off-by: Juraci Paixão Kröhling juraci@kroehling.de

[jpkrohling]

This is still a draft as I'm figuring out what needs to change in terms of CI. Also, I would like to have a word from @bryan-aguilar on what we would need in terms of tooling.

[codecov]

Codecov Report

Base: 91.82% // Head: 91.95% // Increases project coverage by +0.13% 🎉

Coverage data is based on head (9b41beb) compared to base (bdc3e22).
Patch has no changes to coverable lines.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5993      +/-   ##
==========================================
+ Coverage   91.82%   91.95%   +0.13%     
==========================================
  Files         217      217              
  Lines       13337    13319      -18     
==========================================
+ Hits        12247    12248       +1     
+ Misses        861      842      -19     
  Partials      229      229              

Impacted Files	Coverage Δ
exporter/loggingexporter/internal/otlptext/logs.go	100.00% <0.00%> (ø)
service/featuregate/gates.go
service/featuregate/flags.go
featuregate/flags.go	100.00% <0.00%> (ø)
featuregate/gates.go	100.00% <0.00%> (ø)
pdata/pmetric/generated_metrics.go	96.09% <0.00%> (+0.52%)	⬆️
pdata/pcommon/common.go	93.51% <0.00%> (+1.72%)	⬆️
pdata/plog/logs.go	96.29% <0.00%> (+12.42%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[bryan-aguilar]

It's been a little while since I dug into go.work files and their uses but I believe I still have a high level understanding. Without knowing more requirements, if we are looking to centralize around a central go.work file, then adjustments could be made to the crosslink tool to support this. If there are more requirements, multiple go.work files for some reason, then I would need to perform a bit more research on implementation details.

As a note, the initial go.work proposal states that it is not recommended to check in go.work files to version control systems.
go.work files should not be checked into version control repos containing modules so that the go.work file in a module does not end up overriding the configuration a user created themselves outside of the module. The go.work documentation should contain clear warnings about this.

Again, It's been a while since I've done digging into the go.work files so things may have changed. Is this much different than us automatically inserting replacing statements for common modules? Crosslink already addresses that need.

[bogdandrutu]

@jpkrohling @bryan-aguilar while back, @codeboten shared this golang blogpost with me https://go.googlesource.com/proposal/+/master/design/45713-workspace.md#preventing-files-from-being-checked-in-to-repositories

I think their suggestion is different, not sure how do they envision go workspaces to work.

[jpkrohling]

If there are more requirements, multiple go.work files for some reason

That's not the case. I don't think we need that.

As a note, the initial go.work proposal states that it is not recommended to check in go.work files to version control systems.

I wasn't able to find anything authoritative around whether we should or not check in the go.work file, but I found this GitHub issue: golang/go#53502

Apparently, our case is one that would justify checking in the go.work file: a single git repository with multiple modules.

[jpkrohling]

while back, @codeboten shared this golang blogpost with me

That's the proposal @bryan-aguilar linked in his comment.