Using modules and updated library

I have a small test program using a third party package. I also use go1.13.1 and have no GOPATH variable set, but code is in ~/go/src.

I have a go mod file containing

module test-YYY

go 1.13

require github.com/XXX/go-YYY v0.0.0-20170629085401-919a10a449cc

There was an error in the other package, and I submitted a pull request that has just been merged. There is thus a newer commit than the one specified in my go.mod file.

I would like to use the latest version of the package (the one corrected), but go get -u github.com/XXX/go-YYY keeps using the oldest library version and fails to compile because of the error.

Do I have to manually remove the require line in the go.mod file, or is there another way to switch to the latest version of the package ?

EDIT: just tested the manual remove of the require line, and go get -u keeps fetching the previous version instead of the last one. I can’t get go to use the latest and fixed version.

2 Likes

Replying to my self because I managed to solve the issue. I’m still curious to have an explanation on why go wouldn’t take the latest version even though it say it does.

The problem was fixed when using the command

go get -u github.com/XXX/go-YYY@latest

Not sure if the -u is needed. Can’t roll back to try without it.

2 Likes

From my understanding based on the (somehow confusing) documentations:

  1. https://blog.golang.org/using-go-modules
  2. https://github.com/golang/go/wiki/Modules

I believe it did not get updated mainly due to the pseudo-version locked down v0.0.0-20170629085401-919a10a449cc. That explains why when you use @latest, it overrides it (Doc: https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies).

I normally manage go.mod semi-automatically. Basically, I do control the dependencies to avoid the go-bindata disaster in the past.

1 Like

Also, is there any written documents that GOPATH is no longer needed? I can’t find the GOPATH deprecation status and the installation guide still mentions GOPATH is needed (https://golang.org/doc/install#testing).

1 Like

Also, is there any written documents that GOPATH is no longer needed?

Apparently, with go1.13.x, whether GOPATH is defined or not is not relevant. Only the presence of go.mod file is relevant.

If absence of go.mod file, the old system using GOPATH or its default (~/go) is in application. When go.mod is present, the module system is in application.

The command go get -u github.com/XXX/go-YYY@latest can only be used with the module system. With the module system, the instruction go get fetches all packages. This doesn’t work with the old GOPATH system. I was previously confused by this difference in behavior of go get. I didn’t understood why it sometimes worked. It’s the presence of go.mod file.

2 Likes

Noted. Great!

Found that supporting document: https://github.com/golang/go/wiki/SettingGOPATH. It specifically said:

If no  `GOPATH`  is set, it is assumed to be  `$HOME/go`  on Unix systems and  `%USERPROFILE%\go`  on Windows.

That should agrees to all forms of documentations related to Go Modules, where it still relies heavily on GOPATH:

  1. https://golang.org/cmd/go/#hdr-GOPATH_and_Modules
  2. https://golang.org/cmd/go/#hdr-Compile_and_install_packages_and_dependencies

All dots connected and we’re up to “mark as solved”.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.