This journal contain log of edge cases that I found while using Go workspace.
Shared dependency
I have module A than depends on module B and C, with module B also
depends on C.
A -> C A -> B B -> C
There is a bug in module A that caused by C, but not affected on B.
This bug require fixing and breaking changes on function F on C.
Let say the function signature of F changes from
package C func F() (*Node)
to
package C func F() (*Node, int)
I fix it and then run build again on module A.
Since function F also used in module B, the build failed.
I switch to module B, do update as required, and switch back to module `A.
Now A is buildable and pass all tests.
I push module C with fix, pick up the git hash and run "go get -u C@hash"
inside module A, run go mod tidy, commit the changes, and push it.
Turns out the module A failed to build on my CI:
webhook_karajo: ==> Starting build()... webhook_karajo: go run ./internal/cmd/karajo-build embed webhook_karajo: # git.sr.ht/~shulhan/ciigo /build/go/pkg/mod/git.sr.ht/~shulhan/ciigo@v0.15.3/server.go:56:24: \ cannot use ciigo.onGet (value of type func(node *memfs.Node, _ "net/http".ResponseWriter, req *"net/http".Request) (out *memfs.Node)) as "git.sr.ht/~shulhan/pakakeh.go/lib/http".FSHandler value in assignment webhook_karajo: make: *** [Makefile:18: memfs_www.go] Error 1
This is correct behaviour of Go modules, according to
Minimal Version Selection.
Since module A use the latest release of module C, it is also used when
building B.
Because I forgot to push the fix on module B and incorporate it on module
A, the module A fail to build on non-go workspace directory.
The problem is in my local the build run successfully because the go.work
file use the local, non-released version of B.
This human error work flow is not handled when using Go workspace.
In the non-workspace flow, I can use "replace" directive as an indicator in go.mod that said "some dependencies is still in progress and must be fixed and released before we can release this module". Now, this mental model is gone.
The same module inside module
Still in the same repository (module) of A.
I have packaging script in the same repository of A, that clone the
repository A itself inside directory _AUR/src.
. ├── _AUR │ ├── karajo-git │ │ ├── branches │ │ ├── hooks │ │ ├── info │ │ ├── objects │ │ └── refs │ ├── pkg │ │ └── karajo-git │ └── src │ └── karajo-git # <-- git clone of the same module. ...
Building the _AUR package result in the following error,
$ makepkg
...
==> Starting build()...
go run ./internal/cmd/karajo-build embed
main module (git.sr.ht/~shulhan/kilabit.info) does not contain package
git.sr.ht/~shulhan/kilabit.info/_project/src/karajo/_AUR/src/karajo-git/internal/cmd/karajo-build
make: *** [Makefile:18: memfs_www.go] Error 1
==> ERROR: A failure occurred in build().
Aborting...
|
Note
|
Main module (git.sr.ht/~shulhan/kilabit.info) is where I put the
go.work file.
|
I then add the /_project/src/karajo/_AUR/src/karajo-git/ into go
workspace.
Then re-run the makepkg command again.
$ makepkg ... ==> Starting build()... go run ./internal/cmd/karajo-build embed go: module git.sr.ht/~shulhan/karajo appears multiple times in workspace make: *** [Makefile:18: memfs_www.go] Error 1 ==> ERROR: A failure occurred in build().
It now give different error messages.
To fix this we need to set the GOWORK environment variable to off before
running command that use Go tools:
$ GOWORK=off makepkg
This kind of error will never happen on non-workspace work flow.