How Go Mod decide which version to use in `go.mod`

[Chris Duong]

Hi,

I had forked this repo https://github.com/ipedrazas/drone-helm (it used Go Glide for dependencies management).

When I run `go mod init`, it produced `go.mod` with old commit 057547a6f11d in master of this package github.com/ipedrazas/drone-helm

The file is like this:

module github.com/chrisduong/drone-helm

require (

github.com/Sirupsen/logrus v0.0.0-20170713114250-a3f95b5c4235

github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc

github.com/ipedrazas/drone-helm v0.0.0-20180903134347-057547a6f11d

github.com/joho/godotenv v0.0.0-20161216230537-726cc8b906e3

github.com/josmo/drone-helm v0.0.0-20180910175318-692c30089989 // indirect

github.com/urfave/cli v1.19.1

golang.org/x/sys v0.0.0-20170721163517-c4489faa6e5a

)

The commit 057547a6f11d  is not the latest one, while I need to use the latest one. I think I can manual edit `go.mod` to use the latest one. However, I need to know the proper way to make sure Go Mod will download the latest commit in the Master branch as this one. 

I had looked up this Documentation https://tip.golang.org/cmd/go/#hdr-Module_maintenance. But it does not explain the logic Go Mod to choose the version of package to use, like in this case, there is no Semantic Versioning, only use commit in Master branch.

Thanks,

[Chris Duong]

I discovered, Go Mod had seen the Gopkg.lock, so it would use the Versions in that file. So does Go Mod choose the lastest commit of the Master branch, and for repo with Tagging, it will use the latest Tag. Is it correct?

[thepud...@gmail.com]

Hi Chris,

  > "The commit 057547a6f11d  is not the latest one, while I need to use the latest one. I think I can manual edit `go.mod` to use the latest one. However, I need to know the proper way to make sure Go Mod will download the latest commit in the Master branch as this one. "

Typically, upgrading and downgrading of dependencies is done using 'go get', which will automatically update the go.mod file.

Using a branch name such as 'go get github.com/ipedrazas/drone-helm@master' is one way to obtain the latest commit on that branch (master in this case), regardless of whether or not it has a semver tag.

You can read more about the details in the documentation:
  https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get

  https://tip.golang.org/cmd/go/#hdr-Module_queries

Also, the "Modules" wiki page gives a reasonable introduction to how to use modules:

   https://github.com/golang/go/wiki/Modules

Finally, this list 'golang-dev' is for discussing the development of the Go toolchain (for example, changes to the compiler, etc.). For usage questions such as the ones you are asking, you want the 'golang-nuts' group, or you can see this "Questions" wiki page for additional forums: https://github.com/golang/go/wiki/Questions

--thepudds

[thepud...@gmail.com]

Hi Chris,

And a couple more quick points regarding some of your other comments...

Regarding your comment about 'Gopkg.lock':

You are correct that 'go mod init' will use a 'Gopkg.lock' as input when it can.  In order to help provide a smooth migration to modules, 'go mod init' automatically translates the configuration from a reasonably impressive count of 9 pre-existing dependency managers into an initial go.mod file that produces the equivalent build. You can see the list of config types it understands (which includes dep, glide, govendor, and godep) here:

   https://tip.golang.org/pkg/cmd/go/internal/modconv/?m=all#pkg-variables

Regarding your comment about depending on a repo with tagging vs. no tagging: 

If you do 'go get foo' (which is the same as 'go get foo@latest'), it will choose the latest tagged semver release of foo, such as v1.2.3. If there are no semver tagged versions at all of foo, get chooses the latest known commit.There is a bit more nuance about whether or not pre-release tags are used, which is spelled out here (but which I'd summarize as "it does what most people would probably expect"):

  https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get

If instead you add a new import to your source code that is not yet covered by a require in your go.mod, almost any go command (e.g., 'go build') will automatically look up the proper module and add the latest version of that new direct dependency to your module's go.mod as a 'require' directive (where I believe the behavior for determining the latest version in this case is the same as if you had manually run 'go get foo@latest' or 'go get foo').

In any event, that summarizes my personal understanding regarding your questions/comments...

Hope that helps,

--thepudds

[Chris Duong]

Thanks, it is very helpful for me.