♻️ Restructure the project into multiple subprojects - ⚠️ DO NOT MERGE

[acabarbaye]

Description

Major refactoring so that it is possible to use only a subset of the library and have to retrieve just the dependencies needed by such subset. It should speed up build of libraries/tools dependent on this

• Split the utils library into a go.work-based workspace with smaller subprojects, each owning its own go.mod.
• This lets consumers depend on only the specific utility area they need instead of pulling the full monolithic module and all of its transitive dependencies.
• The result is a lighter integration surface, smaller dependency graphs, reduced version-conflict risk, and clearer module boundaries for both consumers and maintainers.

Test Coverage

• This change is covered by existing or additional automated tests.
• Manual testing has been performed (and evidence provided) as automated testing was not feasible.
• Additional tests are not required for this change (e.g. documentation update).

[nirmalsunny]

There are some discussions on whether or not the go work files should be committed.

https://appliedgo.net/spotlight/dont-check-in-gowork/
https://dev.to/rosgluk/go-workspace-structure-from-gopath-to-gowork-35ig

What I did in https://github.com/Arm-Debug/ksc-platform/blob/main/.gitignore was ignore go.work.sum file.

[nirmalsunny]

go work init && go work use -r . should just recreate those files anyway for local development. go.work.sum is known to create conflicts from machine to machine.

[acabarbaye]

the go.work file should be definitely be there as this is so that the utils does not get broken and so that all the subprojects can be released

[acabarbaye]

may be the go.work.sum should be ignored

[acabarbaye]

Having looked at it a bit more and thanks to your links @nirmalsunny It looks like what I was trying to do would not work and go.work does not seem to be the right tool for this. Shame. I am also now a bit confused about what go.work provides as for releasing, go only cares on go.mod and we need to manually upgrade the go entry. Others came up with some tools https://github.com/open-telemetry/opentelemetry-go-build-tools/tree/multimod/v0.30.0/multimod for this but it looks really bespoke and convoluted

[nirmalsunny]

As I understand, go work is to help with local development and not for production. It helps to avoid replace directives in the go mod. This is very developer dependant as different people might use different paths.

While building, go pretty much looks at the go mod for that particular package.