3 ms·

> 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 cu

> 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”. [1] https://godoc.org/golang.org/x/tools/cmd/gomvpkg https://godoc.org/golang.org/x/tools/cmd/gomvpkg > 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.

Groxx 7y ago
>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.
- ainar-g 7y ago
  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.
  - Groxx 7y ago
    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.
    - ainar-g 7y ago
      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.
      - Groxx 7y ago
        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.
        ainar-g 7y ago
        Ah, I see. As far as I know it is vendor-directory-aware. At least it always renamed my packages that imported stuff from vendor/ with no problems. I don't deny that you could have issues with the tool, I simply have never encountered any myself.

Groxx 7y ago

>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.

ainar-g 7y ago
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.
- Groxx 7y ago
  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.
  - ainar-g 7y ago
    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.
    - Groxx 7y ago
      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.
      - ainar-g 7y ago
        Ah, I see. As far as I know it is vendor-directory-aware. At least it always renamed my packages that imported stuff from vendor/ with no problems. I don't deny that you could have issues with the tool, I simply have never encountered any myself.