3 ms·

How do you propose this problem be solved? I was partially responsible for the go-source meta tag thing in the first place. Is there some other mechanism to fin

by enneff 6y ago

How do you propose this problem be solved? I was partially responsible for the go-source meta tag thing in the first place. Is there some other mechanism to find a web-based view of the source of a git repo?

ddevault 6y ago
Well, it's complicated, and we could brainstorm a few ideas. The problem seems to be that this brainstorming session never happened. One problem is that the import path doesn't really give you enough information to totally figure out how to fetch the package. It's treated like a URL, and then the go-source tag comes in to relate it to something VCS-controlled. If we encoded the VCS into the import, we could e.g. have "git+https://git.sr.ht/~sircmpwn/getopt" https://git.sr.ht/~sircmpwn/getopt" as the import path, or we could move the import details into a separate file (like go.mod). But if we assume that the import path and go.mod formats are fixed, then we still have more things we could do. For example, why this: <meta name="go-import" content="git.sr.ht/~sircmpwn/getopt git https://git.sr.ht/~sircmpwn/getopt" /> When we could have this: <link rel="alternate" type="application/x-git-http" "https://git.sr.ht/~sircmpwn/getopt" /> <link rel="alternate" type="application/x-git-ssh" "git@git.sr.ht:~sircmpwn/getopt" /> And why this: <meta name="go-source" content="git.sr.ht/~sircmpwn/getopt https://git.sr.ht/~sircmpwn/getopt https://git.sr.ht/~sircmpwn/getopt/tree/master{/dir} https://git.sr.ht/~sircmpwn/getopt/tree/master{/dir}/{file}#L{line}"> When the same tag could be "source-browser" or something similar? I'm sure many projects other than Go would be very happy to have features like this standardized and available for all of them to use, but the Go team sees no further than its own nose when designing this sort of thing. And furthermore, with the specific case of hardcoded software hosts on pkg.go.dev, why isn't it using the go-source meta tags to look up how to create links to files & line numbers? You guys forced this upon us and then don't even use it? There's no reason to hard-code regexes for various git domains when you could just fetch it like godoc.org does.
- enneff 6y ago
  I agree that it would have been better to design these a little differently. In the first case the go-import meta tag is totally unnecessary. The go tool and module proxy can discover git repos from an import path just fine. It’s only required for “custom” import paths where the path is some domain but the code lives somewhere else, like github. In the latter case the decision to use go-source was actually made by the original author of godoc.org, not a google employee, and was done in coordination with another non-google initiative (gopkg.in) to make their source links work. So nothing to do with the go team really, sorry. https://github.com/golang/gddo/commit/864b1c0aba009e37d301365a2f6f6cf51a3caef3 https://github.com/golang/gddo/commit/864b1c0aba009e37d30136... If pkg.go.dev isn’t respecting go-source meta tags then that should probably be fixed. It would also imo be worth considering devising a more general, well-known mechanism for doing this. Worth proposing I think!
  - ddevault 6y ago
    >In the first case the go-import meta tag is totally unnecessary. The go tool and module proxy can discover git repos from an import path just fine. It’s only required for “custom” import paths where the path is some domain but the code lives somewhere else, like github. The relevant docs are here: https://golang.org/cmd/go/#hdr-Remote_import_paths https://golang.org/cmd/go/#hdr-Remote_import_paths You can explicitly put ".git" into your import path, but no one does this and it's not explained to new users. In order to have predictable import paths like people have been trained to use, you need go-import tags. >In the latter case the decision to use go-source was actually made by the original author of godoc.org, not a google employee, and was done in coordination with another non-google initiative (gopkg.in) to make their source links work. So nothing to do with the go team really, sorry. And yet, godoc.org is what you're replacing. Not taking into consideration is how you end up with what you've got: regression. And this only further betrays Google's warped worldview of "us and only us": this person has made an amazing contribution to Go and yet you consider them an other and don't take their design into account. >If pkg.go.dev isn’t respecting go-source meta tags then that should probably be fixed. It would also imo be worth considering devising a more general, well-known mechanism for doing this. Worth proposing I think! No, it's not worth proposing: it's worth doing, and should have been done in the first place. It should not take an outsider - it should happen naturally from a good engineering ethos. Playing well with others is your burden, not everyone else's.

by enneff 6y ago

ddevault 6y ago

Well, it's complicated, and we could brainstorm a few ideas. The problem seems to be that this brainstorming session never happened. One problem is that the import path doesn't really give you enough information to totally figure out how to fetch the package. It's treated like a URL, and then the go-source tag comes in to relate it to something VCS-controlled. If we encoded the VCS into the import, we could e.g. have "git+https://git.sr.ht/~sircmpwn/getopt" https://git.sr.ht/~sircmpwn/getopt" as the import path, or we could move the import details into a separate file (like go.mod). But if we assume that the import path and go.mod formats are fixed, then we still have more things we could do. For example, why this: <meta name="go-import" content="git.sr.ht/~sircmpwn/getopt git https://git.sr.ht/~sircmpwn/getopt" /> When we could have this: <link rel="alternate" type="application/x-git-http" "https://git.sr.ht/~sircmpwn/getopt" /> <link rel="alternate" type="application/x-git-ssh" "git@git.sr.ht:~sircmpwn/getopt" /> And why this: <meta name="go-source" content="git.sr.ht/~sircmpwn/getopt https://git.sr.ht/~sircmpwn/getopt https://git.sr.ht/~sircmpwn/getopt/tree/master{/dir} https://git.sr.ht/~sircmpwn/getopt/tree/master{/dir}/{file}#L{line}"> When the same tag could be "source-browser" or something similar? I'm sure many projects other than Go would be very happy to have features like this standardized and available for all of them to use, but the Go team sees no further than its own nose when designing this sort of thing. And furthermore, with the specific case of hardcoded software hosts on pkg.go.dev, why isn't it using the go-source meta tags to look up how to create links to files & line numbers? You guys forced this upon us and then don't even use it? There's no reason to hard-code regexes for various git domains when you could just fetch it like godoc.org does.

enneff 6y ago
I agree that it would have been better to design these a little differently. In the first case the go-import meta tag is totally unnecessary. The go tool and module proxy can discover git repos from an import path just fine. It’s only required for “custom” import paths where the path is some domain but the code lives somewhere else, like github. In the latter case the decision to use go-source was actually made by the original author of godoc.org, not a google employee, and was done in coordination with another non-google initiative (gopkg.in) to make their source links work. So nothing to do with the go team really, sorry. https://github.com/golang/gddo/commit/864b1c0aba009e37d301365a2f6f6cf51a3caef3 https://github.com/golang/gddo/commit/864b1c0aba009e37d30136... If pkg.go.dev isn’t respecting go-source meta tags then that should probably be fixed. It would also imo be worth considering devising a more general, well-known mechanism for doing this. Worth proposing I think!
- ddevault 6y ago
  >In the first case the go-import meta tag is totally unnecessary. The go tool and module proxy can discover git repos from an import path just fine. It’s only required for “custom” import paths where the path is some domain but the code lives somewhere else, like github. The relevant docs are here: https://golang.org/cmd/go/#hdr-Remote_import_paths https://golang.org/cmd/go/#hdr-Remote_import_paths You can explicitly put ".git" into your import path, but no one does this and it's not explained to new users. In order to have predictable import paths like people have been trained to use, you need go-import tags. >In the latter case the decision to use go-source was actually made by the original author of godoc.org, not a google employee, and was done in coordination with another non-google initiative (gopkg.in) to make their source links work. So nothing to do with the go team really, sorry. And yet, godoc.org is what you're replacing. Not taking into consideration is how you end up with what you've got: regression. And this only further betrays Google's warped worldview of "us and only us": this person has made an amazing contribution to Go and yet you consider them an other and don't take their design into account. >If pkg.go.dev isn’t respecting go-source meta tags then that should probably be fixed. It would also imo be worth considering devising a more general, well-known mechanism for doing this. Worth proposing I think! No, it's not worth proposing: it's worth doing, and should have been done in the first place. It should not take an outsider - it should happen naturally from a good engineering ethos. Playing well with others is your burden, not everyone else's.