Go Modules Cheat Sheet • Hacker News Board

Re: Go Modules Cheat Sheet

#11

Post by HumblyTossed » Mon, May 03, 2021, 5:41 PM UTC

whateveracct wrote: post #9

HumblyTossed wrote: post #8

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?

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.

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.

Re: Go Modules Cheat Sheet

#12

Post by HumblyTossed » Mon, May 03, 2021, 5:42 PM UTC

q3k wrote: post #10

HumblyTossed wrote: post #8

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?

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

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.

Re: Go Modules Cheat Sheet

#13

Post by trianglesphere » Mon, May 03, 2021, 5:42 PM UTC

HumblyTossed wrote: post #8

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?

All you need to do is have a webpage that has a meta tag with name="go-import" and a content tag with content="URL src-control-method source-control link"

See xyzc.dev/go/ppgen and inspect the source for an example.

Re: Go Modules Cheat Sheet

#14

Post by kodablah » Mon, May 03, 2021, 5:43 PM UTC

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.

Re: Go Modules Cheat Sheet

#15

Post by tsimionescu » Mon, May 03, 2021, 5:47 PM UTC

kodablah wrote: post #14

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.

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?

Re: Go Modules Cheat Sheet

#16

Post by Steltek » Mon, May 03, 2021, 5:47 PM UTC

q3k wrote: post #10

HumblyTossed wrote: post #8

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?

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

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/

Re: Go Modules Cheat Sheet

#17

Post by philwelch » Mon, May 03, 2021, 5:51 PM UTC

tsimionescu wrote: post #15

kodablah wrote: post #14

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.

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?

The original GOPATH approach to dependency management is probably a better fit for monorepos.

Re: Go Modules Cheat Sheet

#18

Post by q3k » Mon, May 03, 2021, 5:56 PM UTC

tsimionescu wrote: post #15

kodablah wrote: post #14

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.

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?

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.

Re: Go Modules Cheat Sheet

#19

Post by coryrc » Mon, May 03, 2021, 5:57 PM UTC

tsimionescu wrote: post #15

kodablah wrote: post #14

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.

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?

We use bazel. It's weird how different it is from the Go cli tooling.

Re: Go Modules Cheat Sheet

#20

Post by Steltek » Mon, May 03, 2021, 5:57 PM UTC

tsimionescu wrote: post #15

kodablah wrote: post #14

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.

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?

I figured GOPATH was designed around the monorepos and they've been trying to get rid of it using the module system.

"/v2", git tags but not branches, and the blast radius of trying to use a forked dependency: Golang's awful module system is top of my list for reasons to recommend away from golang. The design is full of weird kludges and your choices are zero documentation or overwhelming documentation that obscures what you really need.