Cobra: failed to install cobra generator and its dependencies

[akayj]

Go version

go1.15

OS

macOS 10.15.3

What have you done?

follow the guides, run this command
go get -u github.com/spf13/cobra/cobra

What happend?

go: github.com/spf13/cobra/cobra upgrade => v0.0.0-20200815144417-81e0311edd0b go get: github.com/spf13/cobra/[email protected] requires github.com/spf13/[email protected]: reading github.com/spf13/cobra/go.mod at revision v0.0.0: unknown revision v0.0.0

expects

successfully install cobra generator and its deps

[jlhume]

+1
Possibly brought on by #1139 ?

I found running go get -u github.com/spf13/cobra instead will bring in Cobra and it can be used, but you'll have to set up your project manually, as the Cobra generator won't be provided.

[campusstella]

+1

[Adiqq]

Works with:

go get github.com/spf13/cobra/[email protected]

[MichaelMure]

A solution could be to set an explicit version in cobra/go.mod (the secondary go.mod for the CLI tool) but the downside is that this version need to be updated each time a new version is published (and before tagging).

I suppose the replace github.com/spf13/cobra => ../ would still work during development to make sure to use the local code with potential changes.

It's a bit silly that go modules try to get that v0.0.0 version (and fail the whole process) while this version is explicitly overridden.

[akayj]

A solution could be to set an explicit version in cobra/go.mod (the secondary go.mod for the CLI tool) but the downside is that this version need to be updated each time a new version is published (and before tagging).

I suppose the replace github.com/spf13/cobra => ../ would still work during development to make sure to use the local code with potential changes.

It's a bit silly that go modules try to get that v0.0.0 version (and fail the whole process) while this version is explicitly overridden.

Will this solution be marked in the doc later ?
For a dummy, I suppose a notice is welcomed.

[jharshman]

Oddly, I can't seem to recreate this issue on my end. Nonetheless, I have submitted a PR for the solution proposed by @MichaelMure.

[MichaelMure]

Hmm, I'm going to ask the question, but does having viper in the CLI tool (meaning handling the flags with viper, not generating a project with viper included) actually useful ? If not, removing that support would resolve everything at once: no super heavy deps, no double go.mod needed and no weird interaction with it.