I made a mistake described here. Unfortunately that question is wrongly closed as "duplicate", and the proposed question is actually not same as mime.
Let me rephrase my question in another way: as a module author, how can I remove a module from Go's "sumsdb" so that mistake like described can be fixed.
Original question pasted below for reference.
EDIT: this question was closed by moderator, but it is NOT answered by the given uri, which gives a different error message:
Why does go get fail with "invalid version: unknown revision"?
I'll rephrase my questions:
I removed tag v1.0.0 from a commit, and tagged another commit. Now I found that the repository is not usable anymore. To verify: you may just do the following:
Clone https://github.com/xrfang/hap
cd into the example directory, then run go build .
This problem not only happens on my PC, but on anyone trying to use the above repo.
I wonder if the problem will disappear over time (as cache expires?) or I have to do something? If it will heal itself, I wonder how long is the cache valid time? If not, I would like to know how to fix that. I hope not using things like GOPRIVATE, as this repo is going to be public (open source).
original post:
I write a http argument parsing tool, and put it at github.com/xrfang/hap. The git log is:
* d8cee08 2022-02-14 | implemented http.Handler interface (HEAD -> master, tag: v1.0.0, origin/master, origin/HEAD) [xrfang]
* 171dc29 2022-02-10 | updated go.mod for example [xrfang]
* d2cea3c 2022-02-09 | added example [xrfang]
* 202d959 2022-02-09 | bug fix in error handling [xrfang]
* ... ...
Problem is, previouly, I tagged commit d2cea3c as v1.0.0. Later I found it not optimal and added some new code. The new code is NOT compatible with v1.0.0, so I should make it v2.0.0. However, as this tool is newly written and I am the only user. I think it is stupid to make it v2.0.0. So I just removed and retagged v1.0.0 to the latest commit d8cee08.
The problem is, go complained that the version is not "authentic". I then removed go.sum, and did go clean -modcache, go get -u, go mod tidy, to no avail. The last try is:
$ go get -u
# example
./main.go:30:11: at.Init undefined (type apiTest has no field or method Init)
./main.go:39:2: undefined: hap.Register
My questions are:
How does Go manage its repository? I previously found that after I updated my module and push it to github, the example often fail to compile, unless I use replace in go.mod, or just wait for a while (e.g. 30 minute). It seems that there is a central "look up table" which is updated periodically and hence oftem lags behind while modules update?
How to fix my current problem of a re-tagged version?
Your understanding is correct as also described in the question you linked.
Either
Publish v2.0.0
Live with GOPRIVATE
Publish v1.1.0
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.
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.
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"
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.
I'm trying to go get go.etcd.io/etcd/tools/benchmark.
Previously this has worked, flawlessly. However when I try to do it currently I have alternatively got no errors and I've had it fail on me with:
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/balancer_conn_wrappers.go:28:2: use of internal package google.golang.org/grpc/internal/buffer not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:49:2: use of internal package google.golang.org/grpc/internal/resolver/dns not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:50:2: use of internal package google.golang.org/grpc/internal/resolver/passthrough not allowed
The first time I ran it on a new go-1.13 installation it worked, but the following times it has failed as above.
The repo has not changed as far as I can tell in the past 8 months and I've tried on various golang versions but all so far have failed (bar the go-1.13 on that first try...).
Any assistance debugging this would be greatly appreciated!
I have both a workaround and an official fix.
The workaround:
Here I defined a go.mod which then used a previous version of the library.
The official fix:
This was fixed upstream and thus no one else should experience this.
I guess you can try by removing vendor folder from the go.etcd.io/etcd repo. Also disable the vendoring mode. It should work.