I noticed that Pike chose the, uh, “username”, robpike.io for this project. (It’s probably called something else than username in this context.)
What are the benefits of using a domain name as username/organization name in this context?
I noticed that Pike chose the, uh, “username”, robpike.io for this project. (It’s probably called something else than username in this context.)
What are the benefits of using a domain name as username/organization name in this context?
<meta name="go-import" content="import-prefix vcs repo-root">
The code can reside anywhere, independent from the domain in the import path.https://pkg.go.dev/cmd/go#hdr-Remote_import_paths
Edit: I see in another comment that you tried to curl https://robpike.io/ivy and got a 302 redirect to pkg.go.dev. That's meant for humans. You need to add ?go-get=1 for the go toolchain:
$ curl 'https://robpike.io/ivy?go-get=1'
<meta name="go-import" content="robpike.io/cmd/doc git https://github.com/robpike/doc.git"> ...
Personally I don't bother with responding differently based on the go-get query param. I just put a <meta http-equiv="refresh"> alongside the <meta name="go-import"> so that the whole thing can be served statically and still be useful to both humans and machines.It also looks way nicer, and it's easier to deal with (I'd rather type `import ”robpike.io/ivy”` than a GitHub link), but that's a flaw in the way go does packages imo
I see that requesting https://robpike.io/ivy@latest yields a 302 that points to http://godoc.org/robpike.io/ivy@latest (not sure exactly what go install would do with that URL though)
It would be a convenient way to have the package url works for both the package itself and its documentation :).
EDIT: well now for me it redirects to: https://github.com/golang/go/issues/43036 so… whatever is happening here might not be on purpose, actually.
Even works with curl :-)
curl --no-buffer https://robpike.io