Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools/cmd/gomvpkg: fails on build problems elsewhere in the GOPATH #10907
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.
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.