Go workspaces

[ejegrova]

Enable go workspaces in production builds

What are go workspaces?
Workspaces let you work on multiple modules simultaneously without having to edit go.mod files for each module. Each module within a workspace is treated as a main module when resolving dependencies.

With Go workspaces, you control all your dependencies using a go.work file in the root of your workspace directory. The go.work file has use and replace directives that override the individual go.mod files, so there is no need to edit each go.mod file individually.

Example go.work:

go 1.19


use (
  ../foo/bar
  ./baz
)


replace example.com/foo v1.2.3 => example.com/bar v1.4.5

For more detailed info you can check this tutorial or go blog page.

Enabled workspace
if the GOWORK variable names a path to a file that ends in .work
run go env GOWORK to find out (if empty -> workspaces are not enabled)

Typical use cases
Workspaces are flexible and support a variety of workflows. The most common scenarios:

1. Add a feature to an upstream module and use it in your own module
2. Work with multiple interdependent modules in the same repository
3. Switching between dependency configurations

Proposal

Created draft PR (POC)
Tested on repo with go workspaces
Request: cachi2 fetch-deps --source ./source_cachi2/cachi2-go-workspaces/ --output ./cachi2-output '{"type": "gomod", "path": "./api"}'

Main modules
Cachi2 expects only one main module. With the current codebase we get one string that contains the main module and all workspace modules: example.com/m\ngithub.com/gin-gonic/gin and the request fails with KeyError.

Solution:
Set first module as the main module and create ParsedModule for all workspaces.

Purls
Output from the request has wrong purl for module if it is a git submodule:
"purl": "pkg:golang/github.com/gin-gonic/gin@v0.0.0-20231027153741-3cb436cbf1b9?type=module",
which should be:
"purl": "pkg:golang/github.com/ejegrova/cachi2-go-workspaces/gin @v0.0.0-20231124122446-3cb436cbf1b9?type=module",

Solution thoroughly explained here, we'll replace the real path in the Module.

[ben-alkov]

Approvals

• @ben-alkov
• @brunoapimentel
• @eskultety
• @slimreaper35
• @taylormadore

[ben-alkov]

LGTM so far

[brunoapimentel]

This is a brief analysis I did about the matter here, I didn't actually implement it, so I might have overlooked something. Still, I hope it can help you somehow.

We already know that when go list -m returns more than one module, the others are actually linked through a workspace, right?

So, from this list of workspace modules, we need to figure out their relative path from the main module (the one being processed). I think we can figure this out by comparing their location on the disk:

$ go list -m -json

{
	"Path": "example.com/m",
	"Main": true,
	"Dir": "/home/bpimente/Projects/cachito/test-repos/cachi2-go-workspaces/api",
	"GoMod": "/home/bpimente/Projects/cachito/test-repos/cachi2-go-workspaces/api/go.mod",
	"GoVersion": "1.19"
}
{
	"Path": "github.com/gin-gonic/gin",
	"Main": true,
	"Dir": "/home/bpimente/Projects/cachito/test-repos/cachi2-go-workspaces/gin",
	"GoMod": "/home/bpimente/Projects/cachito/test-repos/cachi2-go-workspaces/gin/go.mod",
	"GoVersion": "1.20"
}
{
	"Path": "github.com/bytedance/sonic",
	"Main": true,
	"Dir": "/home/bpimente/Projects/cachito/test-repos/cachi2-go-workspaces/sonic",
	"GoMod": "/home/bpimente/Projects/cachito/test-repos/cachi2-go-workspaces/sonic/go.mod",
	"GoVersion": "1.16"
}

From that, we know that the workspace modules are (and their relative path to the main module):

• github.com/gin-gonic/gin (../gin)
• github.com/bytedance/sonic (../sonic)

The next step would be to replace the real path in the Module list by repo origin + resolved path:

name = github.com/gin-gonic/gin
repo_origin = https://github.com/ejegrova/cachi2-go-workspaces
real_path = https://github.com/ejegrova/cachi2-go-workspaces/gin

From there, the SBOM generation would work as it currently is.

[brunoapimentel]

There could be corner cases such as workspaces that don't live in the root of the repository, or even nested workspaces (:smiling_imp:), which could deviate from the path I described above, so we need to double check for those.

[eskultety]

There could be corner cases such as workspaces that don't live in the root of the repository

You mean workspaces in the dependency or the main module repo being processed? Is that a problem though? Wouldn't "Dir" tell us where that is so that we could infer the workspace relatively to the project root?

even nested workspaces

What's the use case for ^these? Can you give me an example of where that might be useful?

[brunoapimentel]

You mean workspaces in the dependency or the main module repo being processed?

IIUC, workspaces are a parent folder where modules can placed, such as:

• workspace/
  • go.work
  • mymodule/
  • externaldep1/
  • externaldep2/
  • myothermodule/

Which means that the main module being processed is always inside the workspace folder.

Wouldn't "Dir" tell us where that is so that we could infer the workspace relatively to the project root?

Yeah, I believe so. My comment here was mostly to draw attention to corner cases, since I proposed a solution but did not test it thoroughly.

[brunoapimentel]

What's the use case for ^these?

I have no ideia 🤣 But if Go supports it, we need to either support it to, or explicitly forbid it.

[eskultety]

edit: dropped the private URL from the topic description

[ejegrova]

POC tested also on repo: https://github.com/kubernetes-sigs/kustomize/

[eskultety]

The suggested approach LGTM, let me have a look and play a bit with the POC implementation.