-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: drop $GOPATH/pkg #4719
Comments
FYI, for binary-only package to work, you will need to create a dummy "package xxx" Go source file in the directory with an older timestamp than the .a file. This is issue #2775. |
Every release (especially Go 1.5) has been getting us closer to eliminating "pkg" and instead having a build cache directory somewhere (some system-specific cache directory) Having a cache instead of "pkg" would also eliminate the frequent problems people run into where "go build" does too much work when they could've used "go install" instead. /cc @adg @davecheney |
I would love see the pkg directory go away. I've always viewed it as an artifact of our implementation which is based on historic ideas of how a program is compiled into object files which are then linked. (In the earliest days of Go I suggested that we make this compile/link process invisible - i.e., as a programmer one just "sees" source code. But we were not ready at that time for this). |
I view 'pkg' as this cache, and I'm fine with it living inside GOPATH The change I implemented in gb was to remove the distinction between go For my money removing the number of ways one can tell them go tool to cache If that cache lives inside GOPATH, or some default location relative to Thanks Dave On Wed, 30 Sep 2015 03:17 Robert Griesemer notifications@github.com wrote:
|
If the cache is 100% correct (which isn't unimaginable; bazel does it, and Go 1.5 is basically there already), then deleting it is unnecessary. If we really wanted, we could have a Great to hear that If we get to the point where the current "pkg" is just a cache and also cached
|
I cannot explain why people want to delete GOPATH/pkg, I believe it is I'm fine with using the LSB mandates tmp directories, that feels like the On Wed, 30 Sep 2015 07:50 Brad Fitzpatrick notifications@github.com wrote:
|
If pkg is to become a cache, and possibly more hidden, it would be good to fix the ways in which GOOS + GOARCH is not quite a valid cache key: GOARM is probably the worst offender here, but also tags and things like buildmodes and the race detector (although the go tool handles the last two via installstuffix currently). |
Yeah, GOARM/GO386 and build tags (including race) should
also be part of the cache key (ideally, build tag that doesn't
affect the compilation of one package shouldn't be cached
under the cache with the build tag.)
The toolchain version should also be part of the cache key.
Esp. for those who switch Go releases frequently.
|
Forgive me if I have missed subtleties that have already been discussed. I have not seen any discussion of how a system global pkg cache would work for people who switch between multiple GOPATHs, each of which might contain different versions of the same package(s). I understand that recent versions of the go tool will hash all the file names used to build a .a file to help keep the cache accurate. But different versions of a package in different GOPATHs could easily have the same file list but different code. It seems to me either separate caches are required per GOPATH (as the pkg directory does today) or the cache key would need to include something to differentiate between the multiple GOPATHs used. |
Yes, it would have to be a good cache. :-) |
(That is, it would have to take all these things into consideration. It's not a trivial problem, which is why it hasn't happened.) |
+1 to this, particularly making it toolchain-sensitive too. I often find myself switching between different compiler versions so I can check behaviour differences, and switching/removing $GOPATH/pkg is a pain. |
@abitrolly minimal vendor support without GOPATH is being added as part of new modules feature to Go.11. Note Go.1.11 is not released yet. You can try the beta version. |
Change https://golang.org/cl/126755 mentions this issue: |
Using $GOPATH/src/mod confuses too many tools. $GOPATH/pkg/mod seems better for now. It's also next to dep's cache, $GOPATH/pkg/dep. If we do eliminate GOPATH/pkg for holding .a files (#4719) then we could still keep it around for pkg/mod. (Or we could move the module cache again then.) Fixes #26401. Fixes #26635. Change-Id: I18f7da216ed9f490eded3c00d837fb086ae5b6a4 Reviewed-on: https://go-review.googlesource.com/126755 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Rob Pike <r@golang.org>
Change https://golang.org/cl/129679 mentions this issue: |
It's already half gone and later will be all gone. It's not worth explaining in an introduction doc. Fixes #24506 Updates #4719 Change-Id: Ie48128b3aa090d84e0e734aa45f14a4480292913 Reviewed-on: https://go-review.googlesource.com/129679 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
shouldn't the module cache be in os.UserCacheDir() instead of $GOPATH/pkg/mod? |
@perillo, we discussed that (somewhere) earlier and decided to just use $GOPATH/pkg for now while we had it. But yes, it'd have to move later when this bug is resolved. |
@perillo, or we might leave the module source cache in $GOPATH/pkg. I think there are good reasons not to put cached module downloads in $HOME/.cache. Quoting myself on https://dave.cheney.net/2018/07/14/taking-go-modules-for-a-spin and https://groups.google.com/forum/#!msg/golang-dev/RjSj4bGSmsw/KMHhU8fmAwAJ, back when the module cache was $GOPATH/src/mod not $GOPATH/pkg/mod:
I think that's still basically right. If the module cache is the only thing left in $GOPATH/pkg, we could decide to move it elsewhere, or we could decide to leave it there. Moving it to $HOME/.cache seems wrong though. Really I'm just restating what I said in b8f42d7 on Jul 30, 2018 above:
|
@rsc I think I understand and agree with all those points individually, but I'm missing the link between them and being opposed to using My motivation for wanting to use a platform's standard cache location is that these caches tend to grow and never shrink, and eventually it becomes necessary to reclaim some disk space. Having a single location where all "well behaved" software stores caches that are safe to delete makes it more convenient to do that kind of maintenance. Without standards like the XDG base directory spec, most software tends to think it deserves its own entry in your I suspect we have a different level of concern around this point:
I don't think Looking at the XDG data dir spec, if a distinction must be made between the durability of the two go caches, maybe |
I do get rsc's point, some of Go cache is "cheap to discard", some is "expensive to discard and potentially unavailable if lost". Note that XDG says nothing about how For what it's worth, rust seems to plan migrating from |
The other thing a single cache directory location is for is a simple place to exclude things from backups. |
Why will we want a long cache when there will be global modules proxies ? |
This issue was originally about the .a files in $GOPATH/pkg. Those are no longer generated when using the build cache, Since the issue was written, we added $GOPATH/pkg/mod and $GOPATH/pkg/sumdb. Closing this issue as fixed by the now-required build cache. |
The text was updated successfully, but these errors were encountered: