21–30 of 52 posts
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?
Also, Go modules are dependent on DNS, so any domain name change for your repo will have to result in code (import path) changes.
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.
Earlier quoted context omitted.
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.
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.
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?
It isn't, but it is limited to a few source control solutions. If you use something other than Git, Bazaar, SVN, Mercurial, or Fossil, then you're not going to be able to publish Go modules. Also, Go modules are dependent on DNS, so any domain name change for your repo will have to result in code (import path) changes.
Earlier quoted context omitted.
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.
"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 i…
I don't understand? This should literally just be an import statement. If your Git repository is anchored at importpath "source.example.com/git", and your code lives under "app/service/backend", and wants to import "lib/db/mysql", it just does so via `import "source.example.com/git/lib/db/mysql"`. No need to use Go modules at all. Or if you do need to use Go modules, just have one module for the entire repository.
The only reason I can see this not work is if you have multiple Go modules in a single repository, or even worse have module import paths not corresponding to paths within the monorepo. But in that case the fix is easy: just don't do that?
Earlier quoted context omitted.
"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 i…
> "third-party" dependencies can easily exist between teams in the same company sharing the same mono-repo. [...] 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. I don't understand? This should literally just be an import statement. If your Git repository is anchored at importpath "source.example.com/git", and your code lives u…
Modules serve a purpose inside a (large) organization just as between organizations, and tying modules to your source control choices is a generally bad idea.
Earlier quoted context omitted.
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.
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?
[0] - https://blog.bramp.net/post/2017/10/02/vanity-go-import-path...
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.
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
Earlier quoted context omitted.
It isn't, but it is limited to a few source control solutions. If you use something other than Git, Bazaar, SVN, Mercurial, or Fossil, then you're not going to be able to publish Go modules. Also, Go modules are dependent on DNS, so any domain name change for your repo will have to result in code (import path) changes.
A change in your repo does not need to result in an import path change if you set up vanity URLs for your import path. For instance, all my go libraries use the import path of gomod.garykim.dev even though the repos are actually hosted on GitHub. That means if I ever change to self-hosting, for example, I just need to update some of the meta tags on the gomod.garykim.dev website to change the repo location.