18 ms·
I can shed some light on some of your questions for you. > most of the documentation talks of gopath Historically go used a GOPATH env var. Go code had to liv
by mkdirp 4y ago
I can shed some light on some of your questions for you.
> most of the documentation talks of gopath
Historically go used a GOPATH env var. Go code had to live under there under `$GOPATH/src/<module-path>`. When doing an import, go would look at the import path, and find it in GOPATH. This wasn't flexible enough but still exists under the hood as it's where go saves (caches?) packages globally. If you have a go.mod/go.sum file in your project, in general, you won't have to worry about GOPATH.
Worth noting that go, while widely used, was created to solve Google's problems (I guess at least initially?), where (from my understanding) they have a huge monorepo. At that point, having everything live under such a GOPATH somewhat makes sense.
> why are go mod vendor and go mod tidy different commands?
Go mod vendor puts all the dependencies in a ./vendor directory. Often used to commit your packages directly into git. There might be other advantages, not sure, but personally I don't use it. Go is able to pick up the packages in your go.mod directly from $GOPATH.
Go mod tidy ensures your go.mod matches your used package. E.g. if you remove usage of a package in your code, go mod tidy is able to pick that up. In addition, it also ensures your go.sum matches go.mod.
> the lack of “one true way” is very strange. some projects module. some projects check in dependent source code
This is a historic issue. Prior to 1.12 (I think), go modules didn't exist, and there were different community projects that attempted to solve go package management.
> do i download with go get? or go install? or go get -u?
Again, historic issues, iirc go get -u forces an update of a package, meaning this updates your go.mod file. Go get without -u does not force update the package. It update your go.mod file if you haven't included the module previously. Go install is used for go main packages. It fetches the code, builds it (so it must be a main package), and puts the final binary in $GOPATH/bin. Assuming you have that in your patch, you can use it straight away.
- p_l 4y agoGOPATH is arguably more an artifact of Plan9 than google3 monorepo, with Plan9 kinda ending up in monorepo-style access with public replica servers linked at /n/
- na85 4y agoUgh, reading this reminded me why I felt good moving away from Go after the honeymoon period was over. Actually writing the code was fun at first, but everything else around the actual act of composing code was thoroughly awful UX.
- philosopher1234 4y agoCan you elaborate? It seems to me like the minimum set of features I want from package management
- CannisterFlux 4y agoI have a go thing I wrote that I hadn't touched for years but had the misfortune to need to modify it recently, and the way to migrate from $GOPATH/src/ to go.mod is not really clear (to me at least). To build this thing, the only go code I have, I used git submodules to put all the dependencies in ./src, so I had ./src/github.com and a load of 3rd party modules in there, then my code was in ./src/Mything. To build it, I ran "env GOPATH=$PWD go build Mything/MyPackage" and it did the right thing, with the final binary appearing in the current directory. Now this gives an error "go.mod file not found in current directory", but if I add that file, go build says "unexpected go.mod file found in current directory". Luckily, for now, I can use GO111MODULE=off to keep pretending everything is fine, but my eyes start to glaze over when I read the migration guide at https://go.dev/blog/migrating-to-go-modules https://go.dev/blog/migrating-to-go-modules - it's one of those moments where I start to wish I'd used a different language :(
- philosopher1234 4y agoI’m pretty sure the migration is just 1. Go mod init in your code’s root dir 2. Done..? Go get ./…?
- CannisterFlux 4y agoNah, I wish it were it that easy. There is definitely more yak shaving involved. "go mod init" returns the error "go: cannot determine module path for source directory". "go mod init src/mything/mypackage" creates a go.mod file, but then "env GOPATH=$PWD go build mything/mypackage" says "$GOPATH/go.mod exists but should not" (as opposed to when it isn't there, then go complains "go.mod file not found in current directory") Note that "env GOPATH=$PWD GO111MODULE=off go build mything/mypackage" does build all the source code. Most likely I've set the whole project and directory structure up wrong, and it only works by brute force.