Skip to content
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

Consumers are "forced" to use gopkg.in/alecthomas/kingpin.v2 #388

Closed
gravufo opened this issue Apr 19, 2024 · 0 comments · Fixed by #389
Closed

Consumers are "forced" to use gopkg.in/alecthomas/kingpin.v2 #388

gravufo opened this issue Apr 19, 2024 · 0 comments · Fixed by #389
Labels
bug Something isn't working

Comments

@gravufo
Copy link
Contributor

gravufo commented Apr 19, 2024

What happened?

Go projects that reference this project are (almost) forced to use gopkg.in/alecthomas/kingpin.v2 instead of github.com/alecthomas/kingpin/v2.

How can we reproduce it?

Take any project that references this one in its go.mod and try to use github.com/alecthomas/kingpin/v2 in the sub project with a replace such as this:
replace gopkg.in/alecthomas/kingpin.v2 v2.2.6 => github.com/alecthomas/kingpin/v2 v2.4.0

then:

❯ go mod why -m all          
go: github.com/alecthomas/kingpin/v2@v2.4.0 used for two different module paths (github.com/alecthomas/kingpin/v2 and gopkg.in/alecthomas/kingpin.v2)

This returns an exit code of 1, which makes scanning tools (such as Black Duck) fail their scan. This is why it makes it "impossible" for consumers to use the newer module version of kingpin.

What environment did it happen in?

Go version: 1.22

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant