-
Notifications
You must be signed in to change notification settings - Fork 16
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
Module rename has broken indirectly golangci-lint #34
Comments
Hmm, I think go-consistent is only used in ci for go-critic. It shouldn't be a first-class dependency. I'll take a look, thanks. |
I'm having the same problem... 😢 |
I've found a solution, it's not super satisfactory, but seems to work in circleci: |
Refs quasilyte/go-consistent#34 Signed-off-by: Iskander Sharipov <[email protected]>
See the referenced commit. Should help to resolve the problem. |
(I was not struggling with this commit at all. Not a bit. No.) Refs quasilyte/go-consistent#34 Signed-off-by: Iskander Sharipov <[email protected]>
Thanks for this. I tried it out again to see if the issue was resolved by your commit, but it's still happening...
So I'm sticking with the suboptimal solution for now:
|
@quasilyte When modules are enabled, the Is it necessary to change the case for the import path for Changes like that are breaking changes. They can end up having wide repercussions across the ecosystem. For example,
|
go-consistent is not a library and the reason it end up in a dep tree is https://github.com/go-critic/go-critic/blob/master/tools.go. I don't like that a tool that is used during ci tests of go-critic is a dependency of golangci-lint. This is the problem, not the import path, it shouldn't be a dependency on the first place. |
And now import path should match. I've done the renaming in go-critic. |
Hi @quasilyte, With the change you made in go-critic, do upgrades end up working for you? For example, if I do:
It fails during the upgrade step with:
|
That was a synthetic example intended to show the problem more clearly, but here is closer to a real example:
which fails during the upgrade step with:
|
Do you get the revision prior to the fix intentionally? golangci-lint probably uses gocritic version prior to the fix as well. So it needs to be updated. But all that is an issue only if you're using unreleased versions, I think. |
I believe it's mostly true for libraries.
I hear you, but again, those are released libraries intended for public use. Go-consistent is a linter, not something that others can/should depend on inside their modules. The problem is that it made it's way into dependencies tree of golangci-lint. We should probably concentrate on that. This is my point of view. |
FWIW, the new v1.17.0 release of
which fails with:
Some related discussion in golangci/golangci-lint#479. |
try |
Close? |
Should be fixed by go-critic/go-critic#1162 |
Your latest commit
s/Quasilyte/quasilyte
might have broken projects that reference indirectly (maybe even directly, not sure)go-consistent
sincego mod
is case-sensitive and checks the paths (see this issue).I am not sure if this is the right place to report it, but since it is the source of the error, I just wanted to warn you in case it is an unexpected side effect. The dependency chain is
golangci-lint -> go-critic -> go-consistent
.To reproduce:
The text was updated successfully, but these errors were encountered: