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]
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.
As others have already pointed out you don't need to use Github.
Some people call it vanity imports[0].
In my experience 'vanity imports' give better results when googling stuff about custom import paths.
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.
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.
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 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.
[+] [-] throwawaygc123|4 years ago|reply
[0] https://golang.cafe/blog/how-to-upgrade-golang-dependencies....
[1] https://github.com/golang/go/wiki/Modules#how-to-upgrade-and...
[2] https://www.youtube.com/watch?v=AJxKKmzRTUY
[+] [-] 5dd83f0e|4 years ago|reply
[+] [-] tomcam|4 years ago|reply
[+] [-] Thaxll|4 years ago|reply
[+] [-] eandre|4 years ago|reply
[+] [-] HumblyTossed|4 years ago|reply
[+] [-] q3k|4 years ago|reply
https://golang.org/cmd/go/#hdr-Remote_import_paths
[+] [-] nzach|4 years ago|reply
[0] - https://blog.bramp.net/post/2017/10/02/vanity-go-import-path...
[+] [-] trianglesphere|4 years ago|reply
See xyzc.dev/go/ppgen and inspect the source for an example.
[+] [-] whateveracct|4 years ago|reply
[+] [-] tsimionescu|4 years ago|reply
Also, Go modules are dependent on DNS, so any domain name change for your repo will have to result in code (import path) changes.
[+] [-] kodablah|4 years ago|reply
[+] [-] tsimionescu|4 years ago|reply
[+] [-] whateveracct|4 years ago|reply
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|4 years ago|reply
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
[+] [-] dilyevsky|4 years ago|reply