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"
Related
Due to this problem it looks like for providers you have to get a current version of the SDK (2.4.4 at time of post). This post has a lot of info on how to import a specific version of a package but surely every single provider writer isn't manually pulling the most recent version of the SDK (or are they)?
I'm new to Go/Terraform so maybe I'm missing something obvious but the providers I've found (including the official example) have something like:
import(
"github.com/hashicorp/terraform-plugin-sdk/v2/diag"
"github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema"
"github.com/hashicorp/terraform-plugin-sdk/v2/helper/validation"
)
The current version is not 2 - it is 2.4.4. Now I know those are local paths but what confuses me is when I run something like go get it goes and pulls those down for me. I tried doing:
"github.com/hashicorp/terraform-plugin-sdk/v2.4.4/helper/schema"
but go get very much doesn't like that. How is go get finding those package versions? Is there an import syntax that just gets me the latest build or allows me more granularity? I haven't found a good way to tell what version of the SDK I have after running go get but based on this error message:
it looks like I have 2.0 because that error is, as I understand it, fixed in newer versions of the SDK.
I figured it out. The behavior is controlled by the go.mod file.
In there you'll find:
require (
github.com/hashicorp/terraform-plugin-sdk v1.14.0 // indirect
github.com/hashicorp/terraform-plugin-sdk/v2 v2.0.1
As mentioned by #JimB the v2 is the major version for the plugin. v2.0.1 are GitHub tags. Changing this to v2.4.4 obtains the desired behavior.
So here is the situation:
I have a fork of go-ipfs. It depends on go-ipfs-config. I need to modify go-ipfs-config and make go-ipfs depend on my modified version.
I forked the go-ipfs-config made my changes and made sure to update the path to be that of my forked version as can be seen here. I confirmed that this still builds successfully by running go build
Then I updated go.mod in go-ipfs to use my modified version. I used the replace directive to signify this intention which can be seen here
This is where things gets absolutely bunkers and I am no longer sure what is going on.
When i do go mod tidy to fetch the dependency i get the following output:
go: finding module for package github.com/dadepo/go-ipfs-config
go: found github.com/dadepo/go-ipfs-config in github.com/dadepo/go-ipfs-config v0.5.3
The crazy thing is that v0.5.3 does not exist in github.com/dadepo/go-ipfs-config!
Also the following line get added to go.mod :
github.com/dadepo/go-ipfs-config v0.5.3 // indirect
Which can even be seen here
I have run commands like go clean -modcache and go clean -r etc but does not seem to fix things!
Does anybody know what I am doing wrong? And also how to achieve the goal of making my version of a project depend on another modified version of its dependency?
Ok, so this is as a result of me not being aware of couple of things going on in the Go lang toolchain.
Apparently https://proxy.golang.org is a thing! It is a service operated by google that caches modules. So If you made a release, deleted it, chances are that the version is already cached in https://proxy.golang.org. This was exactly what happened in my case. I had made a 0.5.3 release, deleted it, but it is not really gone as the Google cache already got a hold of it.
So in case you are seeing versions that should not exist. This should be the first place you check. This documentation link also sheds some more light on the proxy and how it can be tweaked.
I found this out based on the conversation I had on the issue I opened reporting this behaviour. If you are curious, you can check it out here.
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.
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