A very large issue with go tooling around dependency management is that it's based around concepts like this:
>If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.
Which are effectively fine conceptually. Every dependency system also supports that, you just make a new project named "thing-v2" instead of bumping a major version. Making it explicit and encouraging it when possible (instead of forcing breaking changes) is good.
The problem is that there's absolutely nothing to help you achieve that. Or detect failures to achieve it. Or anything. You can't even reliably rename a single package with existing refactoring tools, good luck copying and refactoring most of an entire repository correctly. If you do it wrong, you might have to do it all over again because it's probably another breaking change.
Without fairly strong tooling to push people towards correct behavior, "every change is breaking" is the default behavior. And the frequent accidental behavior even if you're being careful.
> The problem is that there's absolutely nothing to help you
achieve that. (…)
There were talks about "go mod release" from the very beginning, but you
are currently correct here.
> (…) You can't even reliably rename a single package with existing
refactoring tools. (…)
Strictly false. There is gomvpkg[1]. The absolutely ironic thing is
that it's still stuck in the GOPATH mode, despite being a part of the
official x/tools repo, but it's not “absolutely nothing”.
> Without fairly strong tooling to push people towards correct behavior,
"every change is breaking" is the default behavior. And the frequent
accidental behavior even if you're being careful.
I agree. Honestly, the slow progress in moving the community's
favourite tools, including gomvpkg, to work in the new ecosystem is
a massive failure on the Go authors' side. That just means that they
haven't made the move easy and simple enough.
>Strictly false. There is gomvpkg[1]. The absolutely ironic thing is that it's still stuck in the GOPATH mode, despite being a part of the official x/tools repo, but it's not “absolutely nothing”.
IMO renaming packages is a necessary prerequisite, but otherwise orthogonal to handling breaking changes. Personally I don't include it in the "something that could help" group.
Either way, it's wildly unreliable in my experience, so that point stands.
I've used gomvpkg several times during refactorings and rewrites of
orphaned code and never had an issue with it (in GOPATH mode that is).
But oh well, YMMV, I guess.
By "in GOPATH mode" do you mean it only looks at your GOPATH, not vendor? If so, that could be (part of) the issue - my GOPATH is definitely not up to date with whatever project I'm working on.
Also that'd mean it's a few years behind even basics like the vendor folder, so I'd be comfortable putting it in an "abandonware, effectively does not exist" category.
I've never had the need to rename anything in vendor/, so I can't really
answer here. I've only renamed stuff in my project's internal/. Can
I ask you why did you feel the need to rename something in your vendor/?
It feels completely unnecessary and counter-intuitive to me.
Sorry, I meant "does it only try to use my GOPATH for imports while type-checking my source". My dependencies are in ./vendor, so ignoring it would lead to lots of problems.
Renaming stuff in vendor: almost never. It could be useful for handling library updates though, if it worked and were possible: you could refactor it to the v2 path, automatically updating your code, and then pull the new update for real and be mostly done (for minor-but-breaking changes). I've done similar things in other systems for library updates, since there's usually zero automated migration help for library users, only authors, despite users greatly outnumbering the authors.
>If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.
Which are effectively fine conceptually. Every dependency system also supports that, you just make a new project named "thing-v2" instead of bumping a major version. Making it explicit and encouraging it when possible (instead of forcing breaking changes) is good.
The problem is that there's absolutely nothing to help you achieve that. Or detect failures to achieve it. Or anything. You can't even reliably rename a single package with existing refactoring tools, good luck copying and refactoring most of an entire repository correctly. If you do it wrong, you might have to do it all over again because it's probably another breaking change.
Without fairly strong tooling to push people towards correct behavior, "every change is breaking" is the default behavior. And the frequent accidental behavior even if you're being careful.