Is there a good way to initialize go mods with defaulting to dependency versions in the GOPATH?

user_14011186 0
Viewed 272

I'm starting the process of switching my applications to using go modules from currently not using any dependency manager. I want to use all of the same versions of the dependencies I currently use to avoid the risk of a different version of something causing unforeseen issues. Since I have a microservice architecture with a lot of applications I'm trying to figure out if there's a better way to do this than checking each application and its individual dependencies against what is currently in the build server's GOPATH.

Is there any way, even if just once when first initializing go mods, to have go modules default to the versions in the GOPATH.

If that's not possible (which I have a strong feeling it's not), is it possible to use go list or something similar to print the imported dependencies and the current git sha that exists in the GOPATH?

go-modules go
1 Answers

From the root of your project directory:

go mod init

To pull in build (and optionally test dependencies):

go build ./... # ... notation will scan any subdirectories for any nested packages/tools
go test ./...  # optional

The above will pull the latest (semver) version of each dependency. This may NOT be the version you are using with a GOPATH build.

So to ensure you get the latest commit (which is what GOPATH builds use) - I'd go through each dependency in go.mod and issue a manual update to master. So for example lets say you had logrus as a dependency, to update to the latest commit:

go get github.com/sirupsen/logrus@master

If the latest semver matches the latest commit - no change will occur - but if not you will get a tag version plus commit style pseudo-version.

The Go wiki has other go-modules daily workflows e.g. fast-forward, a month/year from now, to pull the latest version of your dependencies into your go.mod (and go.sum):

go get -u ./...

but again be aware if a dependency does not use semver or has switched to a v2 breaking change - the above will not work.

The best practice is to eyeball the repo:

  • does it support go-modules (i.e. does it have a go.mod at the top level or at the import path level)
  • is the git repo tagged
  • and if the latest commit is tagged

only then can you be sure you are getting the version you expect.

user_12185120
Related