Multi-module workspaces

[lenovouser]

I think currently multi-module workspaces do not seem to be supported, when I try to build caddy with one like this:

xcaddy --with example.net/testing/caddy-test/v1/core=/Users/silas/Workspace/testing/caddy-test

While my caddy-test project contains this go.work file:

go 1.18

use (
	./core // example.net/testing/caddy-test/v1/core
	./state // example.net/testing/caddy-test/v1/state
)

It fails with this:

2022/03/24 17:47:28 [INFO] Build environment ready
2022/03/24 17:47:28 [INFO] Building Caddy
2022/03/24 17:47:28 [INFO] exec (timeout=0s): /usr/local/bin/go mod tidy
go: finding module for package example.net/testing/caddy-test/v1/state/Users/silas/Workspace/testing/caddy-test
caddy imports
	example.net/testing/caddy-test/v1/state/Users/silas/Workspace/testing/caddy-test: module example.net/testing/caddy-test/v1/state@latest found (v0.0.0-00010101000000-000000000000, replaced by /Users/silas/Workspace/testing/caddy-test/state), but does not contain package example.net/testing/caddy-test/v1/state/Users/silas/Workspace/testing/caddy-test
2022/03/24 17:47:30 [INFO] Cleaning up temporary folder: /Users/silas/Workspace/testing/caddy-test/buildenv_2022-03-24-1747.4263064286
2022/03/24 17:47:30 [ERROR] exit status 1

[francislavoie]

Hmm, I have no idea how this is supposed to work. xcaddy basically just runs go mod commands. What would you suggest it needs to do for this to be supported?

[lenovouser]

I got it to work with:

xcaddy \
    --with example.net/testing/caddy-test/v1/core=/Users/silas/Workspace/testing/caddy-test/core  \
    --with example.net/testing/caddy-test/v1/state=/Users/silas/Workspace/testing/caddy-test/state

So this is a good work-around for now, in case anyone else runs into this. Only problem is that you need to add a line for each sub-module you add to the (theoretical) single workspace. One needs to keep that in mind, which most of the time doesn't happen, so it takes a few seconds until you read through the lines of the failure until you get it.

What would you suggest it needs to do for this to be supported?

Ideally it should behave like the plugin project itself when used with Go directly. With Go directly, all the modules I import from other modules in the same multi-module workspace get resolved, everything just works. Even though nothing is actually published anywhere online, so it has no chance of resolving these from somewhere else. It just somehow realizes it is part of a multi-module workspace, and then searches for the related packages in said workspace.

I am not sure why this doesn't already work, because it uses go mod commands already like you said, but I am also not familiar enough with the matter to figure out why it doesn't.

[mholt]

That is strange that it doesn't work. I don't have time to investigate this right now but I really appreciate you sharing a workaround in the meantime!