3 ms·

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

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.

3 ms·

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

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