I have a small library that has always been hosted in a non-module repository but I now want to convert it to a Go module.
I successfully performed:
go mod init
go mod tidy
The go.mod
and go.sum
files were created with no errors and the library still passes testing.
The previous version was v2.0.0
, so I incremented the version to v3.0.0
and added /v3
to the end of the module name in go.mod
. From what I have seen online, that is all that was necessary.
My go.mod
files looks like this:
module tssgit.reyrey.com/teschste/go-utils/v3
go 1.19
require (
github.com/lib/pq v1.10.9
golang.org/x/text v0.9.0
)
I then published the library to our internal git server and thought I was ready to go.
When I attempted to add the library to a new Go module project, I received the following:
Installing: tssgit.reyrey.com/teschste/go-utils/v3
Installing dependency: tssgit.reyrey.com/teschste/go-utils/v3
go: module tssgit.reyrey.com/teschste/go-utils@upgrade found (v2.0.0+incompatible), but does not contain package tssgit.reyrey.com/teschste/go-utils/v3
Failed to add dependencies: exit status 1
I found that if I published v3.0.0
to a new path (tssgit.reyrey.com/teschste/go-utils2
), I was able to successfully add it to my new project, even if I again incremented the major version.
Am I missing something that would allow me to continue publishing in the same path, or is that just something you cannot do?
Any help would be appreciated!
Yes, this is supported. And the version subdirectory is optional.
I found one case that will result in the error you saw. This happens when the main branch is not updated (still points to the tag v2.0.0
) and the new tag v3.0.0
is not pushed to the server. Please check carefully to make sure the remote repository has been updated.
If the remote repository has been updated but it still does not work, you can narrow down the issue like this:
run go get
with the -x
option:
$ go get -x tssgit.reyrey.com/teschste/go-utils/v3
cd
into the directory shown in the output. The directory path is something like this:
/home/username/go/pkg/mod/cache/vcs/96f42aa32430149c99ad6625ceafc5b59e047b9e11d6a03f687d59845b53b2d5
in this directory, run git ls-remote -q origin
and check the output. The example below is the one on my machine when it does not work. You see that both HEAD
and v2.0.0
point to the same commit id, and there is not v3.0.0
.
$ git ls-remote -q origin
5ac4c172806e80461086ea9feb485cec0b6a27f0 HEAD
5ac4c172806e80461086ea9feb485cec0b6a27f0 refs/heads/main
bbdc583c0b83489db1a30fa6ca8559ffa295a74d refs/heads/other-branch
5ac4c172806e80461086ea9feb485cec0b6a27f0 refs/tags/v2.0.0