cmd/go: go install -a mypkg reinstalls standard packages #6424
Milestone
Comments
dave, i think you misunderstood the flag. consider these two commands: go install foo go install -a foo they both consider installing foo and all of foo's dependencies (recursively). the first only builds and installs the ones that are out of date. the second builds and installs all of them, even if they look up-to-date. the problem here is that go install -a my/pkg is trying to reinstall, say, math, but math cannot be written. |
Thanks for your reply Russ. I didn't do a very good job of explaining why I thought -a and a $PKG was incorrect. As an alternative explanation, please consider the way git handles this % git commit -a rpi.go fatal: Paths with -a does not make sense. ^ I think this is a good model for the behaviour of the -a flag with go install, and makes the explanation for why it doens't work simpler; -a will reinstall everything, including the standard library, it will fail if you do not have permission to write to your go installation, most probably if it was installed via your operating systems' distribution mechanism. |
|
Issue #6442 has been merged into this issue. |
Dave, it doesn't matter if the git commit -a behavior would make more sense to git users. It's simply not what go install -a means, and it is too late to change the meaning. For what it's worth, the go install -a behavior matches 'mk -a', or GNU make's make --always-make. Perhaps -a should stop at GOPATH boundaries, just like ordinary builds do. Labels changed: added priority-soon, go1.2, removed priority-triage. Status changed to Thinking. |
I have a few build scripts that `rm -r $GOPATH/pkg` because I run builds with different tags. If I rebuild without rm-ing $GOPATH/pkg, I get the .a files from the previous build. I had hoped that I could use `go install -a` to recompile only those packages that that I depend on in my GOPATH, but my GOROOT is owned by root, not my current user, so I can't rebuild standard library packages for each build (not that I'd want to). I can see how the current behavior could be desirable for someone working on the runtime and standard library, but I don't think it's generally useful, especially if go is installed via a package manager and owned by root. |
|
Comment 14 by admin@802tsn.org: -a may do what it's documented to do, but as noted, it does not solve the problem that I get every time I update the compiler package and there is a mismatch with the libraries on GOPATH. I'd love a flag that means something like "rebuild everything *except* that in GOROOT" ... |
|
I'm still getting the following error on go1.6.2 on mac installed from .pkg Oddly BTW I'm running this command from inside the desired package folder |
|
@robwithhair This issue was closed years ago. If you have a new problem, please open a new issue. Running If you have questions, please use a forum: https://golang.org/wiki/Questions . Thanks. |
|
Change https://golang.org/cl/75850 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Dec 6, 2017
This CL makes "go install" behave the way many users expect: install only the things named on the command line. Future builds still run as fast, thanks to the new build cache (CL 75473). To install dependencies as well (the old behavior), use "go install -i". Actual definitions aside, what most users know and expect of "go install" is that (1) it installs what you asked, and (2) it's fast, unlike "go build". It was fast because it installed dependencies, but installing dependencies confused users repeatedly (see for example #5065, #6424, #10998, #12329, "go build" and "go test" so that they could be "fast" too, but that only created new opportunities for confusion. We also had to add -installsuffix and then -pkgdir, to allow "fast" even when dependencies could not be installed in the usual place. The recent introduction of precise content-based staleness logic means that the go command detects the need for rebuilding packages more often than it used to, with the consequence that "go install" rebuilds and reinstalls dependencies more than it used to. This will create more new opportunities for confusion and will certainly lead to more issues filed like the ones listed above. CL 75743 introduced a build cache, separate from the install locations. That cache makes all operations equally incremental and fast, whether or not the operation is "install" or "build", and whether or not "-i" is used. Installing dependencies is no longer necessary for speed, it has confused users in the past, and the more accurate rebuilds mean that it will confuse users even more often in the future. This CL aims to end all that confusion by not installing dependencies by default. By analogy with "go build -i" and "go test -i", which still install dependencies, this CL introduces "go install -i", which installs dependencies in addition to the things named on the command line. Fixes #5065. Fixes #6424. Fixes #10998. Fixes #12329. Fixes #18981. Fixes #22469. Another step toward #4719. Change-Id: I3d7bc145c3a680e2f26416e182fa0dcf1e2a15e5 Reviewed-on: https://go-review.googlesource.com/75850 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: