-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go get error for 3.4.0 #11154
Comments
Having the same issue with v3.4.1. |
Same here. Would be great to have this fixed. It has been an issue since January. |
Full reproduction:
|
the same, when I use go get: github.com/coreos/[email protected]+incompatible updating to
github.com/coreos/[email protected]+incompatible: parsing go.mod:
module declares its path as: go.etcd.io/etcd
but was required as: github.com/coreos/etcd go.mod has invalid module name |
What was the path you tried to |
go get -u github.com/coreos/etcd
…------------------ 原始邮件 ------------------
发件人: "Gabriel Nelle"<[email protected]>;
发送时间: 2019年10月8日(星期二) 下午4:23
收件人: "etcd-io/etcd"<[email protected]>;
抄送: "Rinker"<[email protected]>; "Comment"<[email protected]>;
主题: Re: [etcd-io/etcd] go get error for 3.4.0 (#11154)
the same, when I use go get -u, I get:
go get: github.com/coreos/[email protected]+incompatible updating to github.com/coreos/[email protected]+incompatible: parsing go.mod: module declares its path as: go.etcd.io/etcd but was required as: github.com/coreos/etcd
go.mod has invalid module name
That was the path you tried to go get -u? github.com/coreos/etcd or go.etcd.io/etcd?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Seeing same issue. |
@moggle-mog: have you tried with Just curious. I worked around it by using |
@tehsphinx Sorry, unavailable again. Because of framework limit, I must use |
Is there a resolution path for this issue? Is there any option other than adding the This change should work for anyone using modules or not, so long they use a Go compiler 1.11 or newer. The part I don't understand is how the old coreos import is affected by this change. |
Tried adding /v3 and /v4 and look for errors in travis - binaries like etcd-dump-logs failed stuck on the incompatible version. |
I originally intended to upgrade etcd to 3.4.2, but at this time, the module is broken, and cannot be included, under the original import path, or the new go.etcd.io import path. See etcd-io/etcd#11154 for more info. Closes #3278 Signed-off-by: Eric Chlebek <[email protected]>
I originally intended to upgrade etcd to 3.4.2, but at this time, the module is broken, and cannot be included, under the original import path, or the new go.etcd.io import path. See etcd-io/etcd#11154 for more info. Closes #3278 Signed-off-by: Eric Chlebek <[email protected]> * Re-write tracing middleware tests to use prometheus_client/testutil (#3342) The testutil package was introduced in v0.9 and exposes some helpers for for writing simple unit tests. Signed-off-by: James Phillips <[email protected]>
I originally intended to upgrade etcd to 3.4.2, but at this time, the module is broken, and cannot be included, under the original import path, or the new go.etcd.io import path. See etcd-io/etcd#11154 for more info. Closes #3278 Signed-off-by: Eric Chlebek <[email protected]> * Re-write tracing middleware tests to use prometheus_client/testutil (#3342) The testutil package was introduced in v0.9 and exposes some helpers for for writing simple unit tests. Signed-off-by: James Phillips <[email protected]>
Can you either please remove the go.mod from the project or fix it? If you are exposing a go module, you should be following its rules. That means that your go.mod needs to expose the actual major version as the module -- The behavior right now is that go modules, despite you having a go.mod, decides that your repo is incompatible and gets the latest tag made, regardless of which branch that tag actually points to. And the only way to get released tags with go modules is to get the commit ID and explicitly use that. If you changed that and Travis broke, please fix Travis. It is unsurprising there would need to be changes since it means that you will have to update import paths. But that is trivial to do, it will make go modules actually work correctly, and it has to be done at some point anyways. |
Here is a temporary workaround (change the v3.4.3 to the tag/release you want)
Take note of the v0.0.0-... (v0.0.0-20191023171146-3cf2f69b5738 for tag v3.4.3 for example) and change your go.mod etcd import like this
It should now work. thanks to https://stackoverflow.com/a/59440771 for the tip on how to compute what's after |
The go.mod file was generated with the following sequence of commands: go mod init go mod tidy The first try resulted in two problems. - One problem was fixed by updating the import path of nats-server to use semantic import v2 in transport/nats/subscriber_test.go. - The other problem was fixed by changing the required version of go.etcd.io/etcd to v0.0.0-20191023171146-3cf2f69b5738 which corresponds to v3.4.3. We cannot use the v3.4.3 tag directly because of problems within the etcd repo itself described in etcd-io/etcd#11154 After those two changes a second go mod tidy succeeds and produces the go.mod file included in this commit.
Hey guys, is there at least a tentative ETA on when this is going to be fixed? |
Please delete EDIT Unfortunately removal of go.mod is not a bulletproof solution either. Quite a few third party packages pull in v3.4.* using a workaround (#11477, great work by obsider). While most imports seem to refer to a specific commit, there is still a risk of breaking one of those workaround imports. One could argue that breaking a workaround is a lesser evil than fixing a bad import bug. Still, afaik there are only two correct approaches:
|
Still doesn't work:
|
@fredczj The maintainers aren't paying attention and don't care anyways. They could solve this issue in two seconds by removing the go.mod entirely but instead they leave an invalid file and cause problems for every single downstream project, and it's been that way for six months. Alternately they could fix this by fixing the import path in go.mod, creating a tag with the new go.mod so that it's actually fetchable (which #11221 failed to do), and fix their CI. More work, but better rewards. We're all just screaming into the void at this point, though. |
For those who cannot wait so do I, I have forked the project and done what @jefferai said. |
@fredczj That's a good idea. Do you think it is possible to use the |
Yes @terorie , this works: in your .go:
then
|
(⊙o⊙)… |
may be for etcd this is beginning of the end |
Let me look into this. I have spent the last 9 months trying to train/empower others to take ownership of infrastructure I have owned throughout the kube ecosystem. And unfortunately part of that has meant I haven’t spent much time focused on any one project. But, this issue seems to still be falling through the cracks for months. So, I will try to figure it out. |
@philips thank you! i'm believe that this is simple |
This will be fixed in etcd v3.5.0 via #11823 |
Thanks, we really need it. Do you have info, when the release? |
@vtolstov Refer to the milestone for release blockers https://github.com/etcd-io/etcd/milestone/37 |
go mod why github.com/coreos/etcd 2 ↵ 6906 17:58:16 |
The correct import path for |
asdsadad |
Can't yet do updates due to issues with etcd: etcd-io/etcd#11749 etcd-io/etcd#11154
it works when add this to go.mod file and wait for v3.5 ... |
This is a very indirect dependency, via eirinix, cobra, viper, etcd. The initial problem is in etcd-v3.3, with an incorrect import of github.com/coreos/bbolt. This is fixed in etcd-v3.4, however, etcd-v3.4 is not a correct go module, and cannot be included in a go mod project! So everyone must wait for etcd-v3.5 to be released with the fix. See etcd-io/etcd#11154 (comment). Until then, we can rename bbolt. Fixing to v1.3.5 is unfortunately required by go.mod's syntax. It should be upgraded if bbolt releases again. Signed-off-by: Danail Branekov <[email protected]>
eirini commit SHA: f5f48da417a4e114fa22212b631594ed5a3ed35c eirini commit message: Fix canonical package name of the bbolt package This is a very indirect dependency, via eirinix, cobra, viper, etcd. The initial problem is in etcd-v3.3, with an incorrect import of github.com/coreos/bbolt. This is fixed in etcd-v3.4, however, etcd-v3.4 is not a correct go module, and cannot be included in a go mod project! So everyone must wait for etcd-v3.5 to be released with the fix. See etcd-io/etcd#11154 (comment). Until then, we can rename bbolt. Fixing to v1.3.5 is unfortunately required by go.mod's syntax. It should be upgraded if bbolt releases again.
Why is this issue closed? Is there a new one we can use for tracking?
It's still not possible to "go get" this library when using modules, although this issue exists for a year now. Both
result in this error
Using the newest commit hash causes yet another issue:
Right now, my go.mod file contains
|
Is this related to #12124? I got it running with the workaround posted there:
The rewrite is required in my own library, as well as every other module/application that depends on my library. ( |
This issue should definitely not be closed, unless another issue (which I haven't seen referenced...) does a better job of explaining the issue or has better conversation. Why the maintainers of this repo -- a repo with functionality needed by many developers -- have been dragging their feet on properly implementing Go modules support and actually, yaknow, maintaining their library is beyond me. |
I understand this is broken in v3.4.z. We, like most of the early adopter Go projects, are put in a tough spot with this migration. As a rule we don’t backport non-bug fixes to the previously released minor versions and if we “fix” this we break everyone who has been using etcd v3.4 (released April 2019) since before Go changed this default. This is closed because it is fixed in the master branch (since #11154 (comment)) and when v3.5 comes out it will (hopefully) be fixed. I understand it is frustrating but we are in a position of not making anyone happy. So, please be considerate and kind when commenting here. |
The text was updated successfully, but these errors were encountered: