Error parsing go.mod module declares its path as: github.com/google/gnostic but was required as: github.com/googleapis/gnostic

[alsofr]

Hi,
the recent change of the module name (from googleapis to google) causes the go get -u ./... command to fail in our project where gnostic is listed as an indirect dependency.

go get: github.com/googleapis/gnostic@v0.5.6: parsing go.mod:
	module declares its path as: github.com/google/gnostic
	        but was required as: github.com/googleapis/gnostic

#259

Manually changing the name and version in the mod file doesn't help.

Is there a recommended smooth update path?

[bcmills]

There isn't a good workaround at the moment for renaming GitHub repositories without breaking Go module users.

I suggest rolling back the name change until golang/go#26904 and/or golang/go#30831 is fixed in the Go toolchain, or moving the repository back to its original name and starting a new (separate) repository for the github.com/google/gnostic path.

[alsofr]

Thanks for the answer and the link @bcmills, it's comforting to see that I'm not the only one struggling with this :)
What is your preferred solution then? Rolling back the change is quite easier, I'm not sure how long it will take for one of the two PRs above to be merged.

[thediveo]

Any news about fixing this? I've got bitten when trying to upgrade the dependencies of a project and now this repo reshuffle blocks this as an indirect dependency stopping go get -u. Please undo this, please!

[alsofr]

The issue goes away when upgrading to go 1.17.3, at least for me.

[thediveo]

Depending on your product build requirements you cannot simply update go just because some module decided to break its import path, and this change has already propagated into other modules depending on it, so projects end up in a dependency hell. This is exactly I was warned of: go modules not being mature and go being not ripe for productivity with lots of complex dependencies. I have to admit: the critics are right on spot here.

[alsofr]

I just thought I would mention it in case someone has the opportunity to upgrade go. If you have to stay on the same golang version, then obviously that solution doesn't help you :(

[Bysmyyr]

The issue goes away when upgrading to go 1.17.3, at least for me.

Not for me