4 ms·

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 m

by 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.
- enneff 6y ago
  > 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. I don’t even know where to begin with addressing this criticism. To say that you have a warped view of the situation is putting it mildly. I’m just going to back out of this conversation while the going is good.
  - ddevault 6y ago
    As far as I can tell it's a pretty frank and accurate observation of the social failings of your engineering process. Google is soulless and trains its engineers to be soulless. Just because it's a hard truth doesn't make it less true. The cognitive dissonance of Google employees online is unreal. You're in a cult.
    - arp242 6y ago
      I'm not a Google engineer, and I mostly agree with the Google engineers. Guess I've joined my first cult! Can anyone tell me the secret handshake? Do I get a decoder ring? Less snarky: it's quite disrespectful simply dismiss an entire group of people as a "cult". You seem to spend significant effort engaging based on the affiliation of the person, rather than what they actually have to say.
      - ddevault 6y ago
        Pot, meet kettle.
- tedunangst 6y ago
  Wait, using the same tag as an existing project to maintain compatibility is proof that Google doesn't play nice and didn't take them into account?
  - ddevault 6y ago

by enneff 6y ago

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.

enneff 6y ago
> 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. I don’t even know where to begin with addressing this criticism. To say that you have a warped view of the situation is putting it mildly. I’m just going to back out of this conversation while the going is good.
- ddevault 6y ago
  As far as I can tell it's a pretty frank and accurate observation of the social failings of your engineering process. Google is soulless and trains its engineers to be soulless. Just because it's a hard truth doesn't make it less true. The cognitive dissonance of Google employees online is unreal. You're in a cult.
  - arp242 6y ago
    I'm not a Google engineer, and I mostly agree with the Google engineers. Guess I've joined my first cult! Can anyone tell me the secret handshake? Do I get a decoder ring? Less snarky: it's quite disrespectful simply dismiss an entire group of people as a "cult". You seem to spend significant effort engaging based on the affiliation of the person, rather than what they actually have to say.
    - ddevault 6y ago
      Pot, meet kettle.
tedunangst 6y ago
Wait, using the same tag as an existing project to maintain compatibility is proof that Google doesn't play nice and didn't take them into account?
- ddevault 6y ago