My go package version is v1.0.7 and now I want to upgrade it to v2.0.0. I create a new tag with it bug when I use go get CODEPATH it still use version v1.0.7. The go.mod should like require CODEPATH v2.0.0+incompatible but I want to know what command will do this?
The document Modules says that add /v2 to module path but didn't tell how to upgrade client's go.mod.
I tried myself and it worked.
Add /v2 to your go.mod's module line module github.com/mnhkahn/aaa/v2;
If you import a sub-package of the module, import like this import "github.com/mnhkahn/aaa/v2/config";
Create a tag with name v2.0.0;
go get github.com/mnhkahn/aaa/v2;
go mod tidy;
The answer from Bryce looks good if you are doing this manually.
If you are interested in an automated approach (for example, perhaps you have many files you would need to visit), a good automated solution is https://github.com/marwan-at-work/mod, which can automatically add, remove, or change the required /vN in your *.go code and your go.mod. See this answer for more details.
Related
My go version is 1.16, local OS is Windows.
I need to use gorose package. When I use the command
go get -u github.com/gohouse/gorose/v2at goland terminal, it shows
go get: github.com/gohouse/gorose/v2#none updating to
github.com/gohouse/gorose/v2#v2.1.10 requires
github.com/gohouse/golib#v0.0.0-20200727025018-43fec7d17e79 requires
github.com/gohouse/e#v0.0.3-rc.0.20200724104652-25ebf8c9c305: invalid pseudo-version: preceding tag (v0.0.3-rc) not found
Anyone can give me a method to solve this problem, thanks.
It appears that github.com/gohouse/e has removed the v0.0.3-rc tag from their repository, so the pseudo-version based on that tag is no longer valid. (Go modules have a strong expectation that maintainers do not delete tags that have already been published.)
One way to work around this problem is to exclude the invalid version, which will cause dependencies on it to be ignored within your module. To do that, add this line to your go.mod file:
exclude github.com/gohouse/e v0.0.3-rc.0.20200724104652-25ebf8c9c305
Then when you go get github.com/gohouse/gorose/v2 it will re-resolve any missing dependencies on package github.com/gohouse/e using the current latest version of that module.
Another way to work around this problem is to obtain a cached copy of v0.0.3-rc.0.20200724104652-25ebf8c9c305 from a Go module proxy. It appears that that version may be cached by proxy.golang.org, which you can use by setting GOPROXY to proxy.golang.org,direct (or unsetting it entirely, since that's the default for most distributions of the go command) in your environment.
If you have set GOPRIVATE and/or GONOPROXY, you may also need to adjust those variables to ensure that they are not bypassing the proxy for github.com/gohouse/e.
Finally, the ideal long-term solution is to fix these dependencies upstream, so that the module dependency graph includes only valid versions to begin with. You could:
file an issue against the github.com/gohouse/e module requesting that they restore the deleted tags, or
send a PR to github.com/gohouse/golib to update the requirement in their go.mod file to a version that is still valid, then send a PR to github.com/gohouse/gorose to update its dependency on golib to the version containing the fix.
There are three different etcd-go package, they are:
github.com/coreos/etcd
go.etcd.io/etcd
go.etcd.io/etcd/v3
According to the commit here, all the
official codes have changed the package from go.etcd.io/etcd to go.etcd.io/etcd/v3 with following messages:
This change makes the etcd package compatible with the existing Go
ecosystem for module versioning.
But I can't get the go.etcd.io/etcd/v3 package by go get command.
So what's the difference between these three etcd-go packages? And how to use them properly.
Thanks in advance.
There is a known issue in the client v3.4 with go get failing. See this issue: https://github.com/etcd-io/etcd/issues/11154
Although the issue has been closed because it is (supposedly) fixed in v3.5, that version is not yet released (when writing this).
There are a few workarounds posted the issue above. The one that worked for us was to circumvent the incorrectly implemented go module of etcd and pin the version to a commit directly in our go.mod file:
require go.etcd.io/etcd v0.0.0-20200520232829-54ba9589114f
The clientv3 is then imported with:
import "go.etcd.io/etcd/clientv3"
The document for no.2 in the question points to this link
https://pkg.go.dev/go.etcd.io/etcd/clientv3?tab=doc
The package has below version and commit hash
v0.5.0 (ae9734e)
The document for no.3 in the question points to this link
https://pkg.go.dev/go.etcd.io/etcd/v3/clientv3?tab=doc
The package has below version and commit hash
v3.3.0 (c20cc05)
etcd would have made a breaking change in latest release and hence changed the module path to differ from the old path. This is a convention recommended in official Golang blog.
Read this blog.
https://blog.golang.org/v2-go-modules
Even though both of them point to the same repo, you have to import these versions differently like below. You can find the correct module path from go.mod file in the root of the repository.
import "go.etcd.io/etcd/clientv3"
import "go.etcd.io/etcd/v3/clientv3"
Sorry, very much a newbie golang question. I have a github project named journalbeat that I am modifying.
When I clone that repository I can set the GOPATH and run go get to grab all the imports and it places them into src.
I have a new import I want to add.
import "github.com/danwakefield/fnmatch"
but it doesn't grab it. How does simply running go get determine whether something is downloaded or not?
And finally, the vendoring system is used. How do I populate that with the fnmatch? do I create it manually? it all seems very cumbersome.
I thought go get was meant to make all this easy?
Try instead a dependency manager: the most recent and actively developed one is golang/dep.
Reading dep "issue" 943, use:
dep ensure
That will set up vendored dependencies through import analysis, and you can configure locking those down if need be.
Try go get with the verbose flag -v like:
go get -v github.com/danwakefield/fnmatch
This will show you more details. Post the result here.
we use Glide package management tool for GO. Go check it out gitHub link
New Go programmer here -- apologies if this is well worn territory, but my google searching hasn't turned up the answer I'm looking for.
Short Version: Can I, as a programmer external to the core Go project, force my packages to be imported with a specific name. If so, how?
Long Version: I recently tried to install the bcrypt package from the following GitHub repository, with the following go get
go get github.com/golang/crypto
The package downloaded correctly into my workspace, but when I tried to import it, I got the following error
$ go run main.go main.go:10:2: code in directory /path/to/go/src/github.com/golang/crypto/bcrypt expects import "golang.org/x/crypto/bcrypt"
i.e. something told Go this package was supposed to be imported with golang.org/x/crypto/bcrypt. This tipped me off that what I actually wanted was
go get golang.org/x/crypto/bcrypt
I'd like to do something similar in my own packages — is this functionality built into Go packaging? Or are the authors of crypto/bcrypt doing something at runtime to detect and reject invalid package import names?
Yes it's built in, I can't seem to find the implementation document (it's a relatively new feature in 1.5 or 1.6) however the syntax is:
package name // import "your-custom-path"
Example: https://github.com/golang/crypto/blob/master/bcrypt/bcrypt.go#L7
// edit
The design document for this feature is https://docs.google.com/document/d/1jVFkZTcYbNLaTxXD9OcGfn7vYv5hWtPx9--lTx1gPMs/edit
// edit
#JimB pointed out to https://golang.org/cmd/go/#hdr-Import_path_checking, and in the go1.4 release notes: https://golang.org/doc/go1.4#canonicalimports
How do you use go vendoring. It is written many places that 1.6 now include vendoring, but I can not find any documentation?
When use go get, I see no vendor folder?
I just need to be able to control packages like npm, apt etc.
As of 1.5 (with a flag) and 1.6 by default the go tools will look in the vendor folder for dependant packages before your GOPATH, for specifics see the design doc
But the go tools do not include tooling to populate that folder for you.
There are many tools that try to handle it for you, for example Godep, gvt and others.
You still need to use go get to get the packages into your GOPATH first.