7 ms·

Go Modules Cheat Sheet

138 points by eandre 5y ago

tomcam 5y ago
Ahhhh.... relief. The Go docs are vague on day-today tasks like this. Also how were those nifty arrows done?
- Thaxll 5y ago
  vague? https://github.com/golang/go/wiki/Modules#daily-workflow https://github.com/golang/go/wiki/Modules#daily-workflow
  - geodel 5y ago
    But I am millennial. I do not have time to read any document. There must be a way to just know about this or any other thing without ever learning about it.
    - rainworld 5y ago
      Arguably updating packages could be a bit more obvious than go get (-d) -u ./... && go mod tidy
      - morelisp 5y ago
        In 99% of cases you only need go get -u
  - tomcam 5y ago
    I stand very happily corrected! Thank you very much!
- eandre 5y ago
  Thanks! I used Illustrator to create it and then cleaned it up by hand.
HumblyTossed 5y ago
Question: Why is go so integrated(?) with github? I mean, why can't I (or can I?) go get from my own personal gitlab server?
- whateveracct 5y ago
  I think you can? The urls in package names are just urls. So if you have a url to a git repo, it'll work.
  - HumblyTossed 5y ago
    Okay, interesting. I tried looking that up, but I never once found an example and, well, I simply never thought to try it. Thank you.
- q3k 5y ago
  You can. If you have a `.git` in your import path, it should just work OOTB, using Git as expected. Otherwise, whatever code hosting service has to implement support for returning a proprietary meta tag when serving a ?go-get=1 query - and Gitlab already does that, IIRC. https://golang.org/cmd/go/#hdr-Remote_import_paths https://golang.org/cmd/go/#hdr-Remote_import_paths
  - HumblyTossed 5y ago
    Thank you for the link. I have tried in the past to find this exact information and for some reason it just never came up. User error, I suppose.
  - Steltek 5y ago
    For a truly private server, you'll need two needles of that mountainous haystack: set GOPRIVATE and tell git to use ssh first: git config --global url.git@HOSTNAME:.insteadOf https://HOSTNAME/
    - gbear0 5y ago
      Is there not a better solution for this? We have this baked into our docker builds and it irks me that we have to copy personal credentials into a docker build so we can use git to pull modules and build. Is everyone actually doing this, or do you setup read-only tokens per private module, or anything else?
kodablah 5y ago
I've found explaining multi-module repos w/ go.mod files in subdirs and how that affects using a pseudo-version vs a real version to be the most challenging part. That could be a good addition.
- tsimionescu 5y ago
  I'm always surprised just how difficult it is to have Go code in a monorepo given Google's famous use of one. I guess they just don't use modules internally?
  - philwelch 5y ago
    The original GOPATH approach to dependency management is probably a better fit for monorepos.
    - tsimionescu 5y ago
      That's only true if everyone uses the latest version of the code. If you want to have an internal package ecosystem, with stable versions of packages, feature branches etc, then GOPATH is an even worse kludge.
  - q3k 5y ago
    It works great if you don't use modules internally. Either go with plain GOPATH, or use something like Bazel/rules_go/Gazelle. Modules are not for monorepos and internal components, modules are for third party dependencies that need to be pulled in at compatible versions, and for general multirepo work.
    - tsimionescu 5y ago
      "third-party" dependencies can easily exist between teams in the same company sharing the same mono-repo. It's perhaps not as common with git, but other version control systems are much more often used as monorepos, often for building multiple unrelated projects, with some common tooling libraries used as modules. This is trivial to do with any other module system I've used (Maven, Nuget, Konan, pip, cargo), but it is extraordinarily brittle with Go.
whateveracct 5y ago
I want to be on the new wave of Go modules, but a Nix-managed GOPATH works just as well if not better, especially if you use niv to manage the hashes & versioning. This is considering the fact that nixpkgs has Go module support. You can even use Nix's recursive, lazy nature to declare dependencies between libraries too in an equally lighweight way as go mod.
- cle 5y ago
  I agree that GOPATH makes integration with other package managers much easier. However, this is a lost cause at this point. Go is removing GOPATH support in the next release (Go 1.17). See: https://blog.golang.org/go116-module-changes https://blog.golang.org/go116-module-changes
  - whateveracct 5y ago
    That's a real shame!
dilyevsky 5y ago
Missing go mod download -json for when you want to print the checksums (e.g when adding bazel to external repo)
throwawaygc123 5y ago
i have also written an article given my frustration in finding simple information on the topic ie. how to upgrade go deps[0] which is not immediately easy to find from the extensive Go wiki[1] and a general go mod how-tos tutorial[2] [0] https://golang.cafe/blog/how-to-upgrade-golang-dependencies.html https://golang.cafe/blog/how-to-upgrade-golang-dependencies.... [1] https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies https://github.com/golang/go/wiki/Modules#how-to-upgrade-and... [2] https://www.youtube.com/watch?v=AJxKKmzRTUY https://www.youtube.com/watch?v=AJxKKmzRTUY
- 5dd83f0e 5y ago
  Why did you decide not contributing to the wiki? (curious, not blaming tone)
  - throwawaygc123 5y ago
    the wiki already have enough information - it is in my opinion structured and packed in a way that is difficult to find. I think if it would be possible to split the Modules wiki into multiple search-engine-indexable files - info will be slightly easier to find

138 points by eandre 5y ago

tomcam 5y ago

Ahhhh.... relief. The Go docs are vague on day-today tasks like this. Also how were those nifty arrows done?

Thaxll 5y ago
vague? https://github.com/golang/go/wiki/Modules#daily-workflow https://github.com/golang/go/wiki/Modules#daily-workflow
- geodel 5y ago
  But I am millennial. I do not have time to read any document. There must be a way to just know about this or any other thing without ever learning about it.
  - rainworld 5y ago
    Arguably updating packages could be a bit more obvious than go get (-d) -u ./... && go mod tidy
    - morelisp 5y ago
      In 99% of cases you only need go get -u
- tomcam 5y ago
  I stand very happily corrected! Thank you very much!
eandre 5y ago
Thanks! I used Illustrator to create it and then cleaned it up by hand.

HumblyTossed 5y ago

Question: Why is go so integrated(?) with github? I mean, why can't I (or can I?) go get from my own personal gitlab server?

whateveracct 5y ago
I think you can? The urls in package names are just urls. So if you have a url to a git repo, it'll work.
- HumblyTossed 5y ago
  Okay, interesting. I tried looking that up, but I never once found an example and, well, I simply never thought to try it. Thank you.
q3k 5y ago
You can. If you have a `.git` in your import path, it should just work OOTB, using Git as expected. Otherwise, whatever code hosting service has to implement support for returning a proprietary meta tag when serving a ?go-get=1 query - and Gitlab already does that, IIRC. https://golang.org/cmd/go/#hdr-Remote_import_paths https://golang.org/cmd/go/#hdr-Remote_import_paths
- HumblyTossed 5y ago
  Thank you for the link. I have tried in the past to find this exact information and for some reason it just never came up. User error, I suppose.
- Steltek 5y ago
  For a truly private server, you'll need two needles of that mountainous haystack: set GOPRIVATE and tell git to use ssh first: git config --global url.git@HOSTNAME:.insteadOf https://HOSTNAME/
  - gbear0 5y ago
    Is there not a better solution for this? We have this baked into our docker builds and it irks me that we have to copy personal credentials into a docker build so we can use git to pull modules and build. Is everyone actually doing this, or do you setup read-only tokens per private module, or anything else?

kodablah 5y ago

I've found explaining multi-module repos w/ go.mod files in subdirs and how that affects using a pseudo-version vs a real version to be the most challenging part. That could be a good addition.

tsimionescu 5y ago
I'm always surprised just how difficult it is to have Go code in a monorepo given Google's famous use of one. I guess they just don't use modules internally?
- philwelch 5y ago
  The original GOPATH approach to dependency management is probably a better fit for monorepos.
  - tsimionescu 5y ago
    That's only true if everyone uses the latest version of the code. If you want to have an internal package ecosystem, with stable versions of packages, feature branches etc, then GOPATH is an even worse kludge.
- q3k 5y ago
  It works great if you don't use modules internally. Either go with plain GOPATH, or use something like Bazel/rules_go/Gazelle. Modules are not for monorepos and internal components, modules are for third party dependencies that need to be pulled in at compatible versions, and for general multirepo work.
  - tsimionescu 5y ago
    "third-party" dependencies can easily exist between teams in the same company sharing the same mono-repo. It's perhaps not as common with git, but other version control systems are much more often used as monorepos, often for building multiple unrelated projects, with some common tooling libraries used as modules. This is trivial to do with any other module system I've used (Maven, Nuget, Konan, pip, cargo), but it is extraordinarily brittle with Go.

whateveracct 5y ago

I want to be on the new wave of Go modules, but a Nix-managed GOPATH works just as well if not better, especially if you use niv to manage the hashes & versioning. This is considering the fact that nixpkgs has Go module support. You can even use Nix's recursive, lazy nature to declare dependencies between libraries too in an equally lighweight way as go mod.

cle 5y ago
I agree that GOPATH makes integration with other package managers much easier. However, this is a lost cause at this point. Go is removing GOPATH support in the next release (Go 1.17). See: https://blog.golang.org/go116-module-changes https://blog.golang.org/go116-module-changes
- whateveracct 5y ago
  That's a real shame!

dilyevsky 5y ago

Missing go mod download -json for when you want to print the checksums (e.g when adding bazel to external repo)

throwawaygc123 5y ago

i have also written an article given my frustration in finding simple information on the topic ie. how to upgrade go deps[0] which is not immediately easy to find from the extensive Go wiki[1] and a general go mod how-tos tutorial[2] [0] https://golang.cafe/blog/how-to-upgrade-golang-dependencies.html https://golang.cafe/blog/how-to-upgrade-golang-dependencies.... [1] https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies https://github.com/golang/go/wiki/Modules#how-to-upgrade-and... [2] https://www.youtube.com/watch?v=AJxKKmzRTUY https://www.youtube.com/watch?v=AJxKKmzRTUY

5dd83f0e 5y ago
Why did you decide not contributing to the wiki? (curious, not blaming tone)
- throwawaygc123 5y ago
  the wiki already have enough information - it is in my opinion structured and packed in a way that is difficult to find. I think if it would be possible to split the Modules wiki into multiple search-engine-indexable files - info will be slightly easier to find