Re: [Libguestfs] Publishing the libnbd go module

On Mon, Oct 25, 2021 at 04:45:03PM +0300, Nir Soffer wrote: > I'm playing with libnbd go module, planning to use it in a new command[1] > > The biggest obstacle for me is that the module is not published in a way that > Go developers expect. > > The module is listed in: > https://pkg.go.dev/github.com/libguestfs/libnbd/golang > > But the module actually lives in: > https://github.com/libguestfs/libnbd/tree/master/golang/src/libguestfs.or... > > So the pkg.go.dev page is broken, .e.g no there is no documation or license, and > the suggested import is wrong. > > The module name is "libguestfs.org/libnbd". But if you try to use it, > for example > in the (improved) example from libnbd-golang.pod: > > $ cat test.go > package main > > import "fmt" > import "libguestfs.org/libnbd" > > func main() { > h, err := libnbd.Create() > if err != nil { > panic(err) > } > defer h.Close() > uri := "nbd://localhost" > err = h.ConnectUri(uri) > if err != nil { > panic(err) > } > size, err := h.GetSize() > if err != nil { > panic(err) > } > fmt.Printf("size of %s = %d\n", uri, size) > } > > $ go mod init example/test > go: creating new go.mod: module example/test > go: to add module requirements and sums: > go mod tidy > > $ go mod tidy > go: finding module for package libguestfs.org/libnbd > example/test imports > libguestfs.org/libnbd: cannot find module providing package > libguestfs.org/libnbd: unrecognized import path > "libguestfs.org/libnbd": reading > https://libguestfs.org/libnbd?go-get=1: 404 Not Found > > If we use libguestfs.org, https://libguestfs.org/libnbd?go-get=1 > should return the expected > metadata instead of 404. > > But even if "libguestfs.org/libnbd" would work, we cannot use the > module from the source > since the source is missing the generated files (wrappers.go, binding.go, ...). > > It looks like the only ways to use the module are: > > - Vendor the go code from the tarball. > > I did not try this since I don't want to copy libnbd into source into > my project. > > - Clone and build libnbd locally, and replace libguestfs.org with the > path to your local source > > $ go mod edit -replace > libguestfs.org/libnbd=../../src/libnbd/golang/src/libguestfs.org/libnbd > $ go mod tidy > go: found libguestfs.org/libnbd in libguestfs.org/libnbd > v0.0.0-00010101000000-000000000000 > > $ cat go.mod > module example/test > > go 1.16 > > replace libguestfs.org/libnbd => > ../../src/libnbd/golang/src/libguestfs.org/libnbd > > require libguestfs.org/libnbd v0.0.0-00010101000000-000000000000 > > > But the version is wrong - it should be v1.10.0. > I think the issue is missing tag: > https://golang.org/ref/mod#vcs-version > > If a module is defined in a subdirectory within the repository, > that is, the module subdirectory > portion of the module path is not empty, then each tag name must > be prefixed with the module > subdirectory, followed by a slash. For example, the module > golang.org/x/tools/gopls is defined > in the gopls subdirectory of the repository with root path > golang.org/x/tools. The version v0.4.0 > of that module must have the tag named gopls/v0.4.0 in that repository. > > So the linbd project needs a tag like: > golang/src/libguestfs.org/libnbd/v1.10.0 > > Removing the "src/libguestfs.org" directories will clean things up: > golang/libnbd/v1.10.0 Go modules are a bit annoying in that they're effectively designed around the use of semver for versioning. Anything from v2.xxxx onwards means you need to put the module code in sub-directory named after the major version number. This means all your apps need to update their imports any time you change major version. In libvirt's go modules we had to re-create the git repos with new tags based on semver instead of calver, to get out of the ever changing sub-directory trap. libnbd is lucky that it is still on v1.xxxx, so isn't in the sub-dir naming trap yet. I feel like as a general rule life is simpler if the Go code is all in a dedicated repo, completely separate from any other non-Go code, and any auto-generated code is committed too, and wired up such that "go gen" will trigger whatever command is needed to re-generate. Assuming you don't want to change libnbd build system at all though, you could have a separate git repo where you import the generated Go binding at time of each release. It'll still get a little odd when people want to submit bugs/patches, as they will need to know to submit to the main repo, not this import-only repo.