go4.org repo collides with go4.org/grpc

[adg]

If you do this

$ go get go4.org/grpc
$ go get go4.org/types

then the second command fails.

This is because go get doesn't support nested repositories, and it's not clear that this can or should work (there should be a corresponding issue for cmd/go; will file it). The workaround is to perform the commands in the opposite order.

[mpl]

Ah I understand, thanks.
that's unfortunate.

[mpl]

@bradfitz wouldn't it be enough to change

content="go4.org/grpc

into

content="go4.org

in the meta HTML returned by https://go4.org/grpc ?

I've never played with meta yet, so I'm going to test and see on a dummy repo.

Edit: ah nevermind, I see now that this would pull the contents of https://github.com/go4org/grpc directly into GOPATH/src/go4.org , which is def not what we want.

[mpl]

ok, I think this would work:

1. merge Move everything into a grpc dir grpc#1

2. change the meta tag at https://go4.org/grpc

to:

<meta name="go-import" content="go4.org git https://github.com/go4org/grpc">

WDYT?

[bradfitz]

I'd rather not move everything down a directory in my fork, as I'm trying to keep the git history and file layout roughly compatible (and comparable) with the official grpc-go upstream git repo. That's why I didn't just copy everything into go4's git repo, for instance.

If I'd known about this problem before, I wouldn't have gone this route and I might've used a subdomain of go4.org instead. Maybe I still should, even if import "grpc.go4.org/grpc" isn't as pretty of an import.

Still thinking. Ideas welcome.

[dmitshur]

even if import "grpc.go4.org/grpc" isn't as pretty of an import.

Have you considered an import "grpc.go4.org" import path instead? Less stuttering. I'm not aware of a reason it wouldn't work; is there one?

You'd want https://grpc.go4.org?go-get=1 to serve:

<meta name="go-import" content="grpc.go4.org git https://github.com/go4org/grpc">

[bradfitz]

Have you considered an import "grpc.go4.org" import path instead? Less stuttering. I'm not aware of a reason it wouldn't work; is there one?

Interesting thought.

Are there examples of anybody else doing this?

The closest I can think of is "golang.org/x/oauth2" which is only interesting in that its package files are in the root of its git repo and not under a subdirectory.

But yeah, I can't think of why that wouldn't work.

[dmitshur]

Are there examples of anybody else doing this?

What exactly are you referring to by "this"? Using the root of a domain as a custom import path of a Go package, or something else?

One example I can think off the top of my head is:

• goji.io

(I'm aware of it from golang/go#13506 and golang/gddo#355.)

The closest I can think of is "golang.org/x/oauth2" which is only interesting in that its package files are in the root of its git repo and not under a subdirectory.

That's pretty common, most projects that have custom import paths are at the root of the git repo, e.g.:

• rsc.io/pdf (source is https://github.com/rsc/pdf, .go files are in repo root)
• honnef.co/go/js/dom (source is https://github.com/dominikh/go-js-dom, .go files in repo root)
• robpike.io/ivy (source is https://github.com/robpike/ivy, .go files are in repo root)

[bradfitz]

Yes, "this" == "root of a domain as a custom import path".

Super excited to hear that works. I'll set that up now.

Thanks!

[bradfitz]

Done.

Let me know if there are problems or parts I forgot.

Thanks!

[dmitshur]

Super excited to hear that works.

It's one of the things I really appreciate about Go (and contribute fixes when needed): it's simple and has few unexpected edge cases. Vanity import paths are just schema-less URLs, and a URL with the path value "/" (i.e., domain root) is no more special than "/foo/bar", so it's nice that it works equally well as an import path. 😊

[dmitshur]

This is because go get doesn't support nested repositories, and it's not clear that this can or should work (there should be a corresponding issue for cmd/go; will file it).

The situation with nested/overlapping repositories is interesting. @adg, did you file that cmd/go issue? What number is it? I'd like to follow it.

[bradfitz]

He didn't. Feel free to file one yourself?