x/tools/cmd/gomvpkg: fails on build problems elsewhere in the GOPATH #10907
Comments
|
What if the package in error uses the old import of the
package being moved?
I think gomvpkg is working as intended here. If you
don't care about that package, then it shouldn't be
in the GOPATH when invoking gomvpkg.
|
|
Well, the short answer is to emit a log message, and move on because if they care about it, they'll run into the build issue and run gofmt -r or sed to fix it. I understand your point. However, it seems likely that most folks will have dirty GOPATHs. Even popular projects like bmizerany/pat had multiple packages in an example directory, breaking these tools when they hit it, for a very long time. We all accumulate checkouts of projects either aren't up to our standards or depend on other things. Expecting each engineer to track every dependency of things that they, say, only use a simple binary of, and then expect them to know how to fix them to run a refactoring tool on their own code is is a lot to ask of them. Not all of us are senior engineers who can just dive in and know how to fix the problem and do so quickly. And those senior engineers that do are often the ones most strapped for time. On top of that, it's often recommended that $GOPATH be set to $HOME (I even recommend it!) and I think the users could be forgiven for trying to reuse a directory named ~/src. As Go becomes more popular, tools like go-mode.el and google-cloud-sdk (which refers to a appengine package that can't be found by normal tools) are going to end up in $GOPATH. This is going to become a worse problem, not a better one, over time. Finally, Lots of the same tools that use buildutil are also going to have to learn about partially compiling projects in order to perform useful refactors just like IDEs can do. These errors from gomvpkg/buildutil are just a part of that same use case. Engineers are often performing changes in multiple files at once, but know that they can get it back to a resolvable form. Nice refactoring tools accommodate that. We can't get every open source project and its dependencies to be perfect in their repositories, and we can't stop folks from putting things in $GOPATH that don't build, and we can't fix up the code for them if they're too strapped for time or experience, but we can make the tools do nicer things when they run. |
|
actually, i don't think it's recommended to run gomvpkg with a huge GOPATH
because it could potentially touch a lot of packages, some of which might
not be intended.
A better way is to synthesize a temporary GOPATH, with just the packages
you care about, and run gomvpkg there.
|
|
CL https://golang.org/cl/10715 mentions this issue. |
And in gomvpkg, don't stop just because some packages had errors. This is inevitable in a large GOPATH tree. Fixes issue golang/go#10907 Change-Id: I9a60b070228d06d44880202eeef54394e914f5d5 Reviewed-on: https://go-review.googlesource.com/10715 Reviewed-by: Sameer Ajmani <sameer@golang.org>
gopherbot
added
the
Tools
Was calling
gomvpkg -from github.com/jmhodges/foobar/baz -to github.com/jmhodges/foobar/quux
and gomvpkg errored out with
These packages are unrelated and it would be nice for gomvpkg to be able to build errors in unrelated areas. This might have to be an additional feature of buildutil.
The text was updated successfully, but these errors were encountered: