Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

types/known: one home for the WKTs (Well Known Types) #218

Closed
awalterschulze opened this issue Aug 21, 2016 · 3 comments
Closed

types/known: one home for the WKTs (Well Known Types) #218

awalterschulze opened this issue Aug 21, 2016 · 3 comments

Comments

@awalterschulze
Copy link

How are the .pb.go files going to end up in one home.
Continuing this discussion in #143

Ok so the idea is that all the code generated in ptypes will move to https://github.com/google/go-genproto
So each user of proto3 wkts will now also have to import this new package.

Also unlike ptypes which has each proto and pb.go in its own package go-genproto has all the protos and .pb.go files in one package called protobuf.

What is the eventual plan for this?
Is moving all these pb.go files into one home really depending on this very contentions issue:
https://golang.org/issue/16339
Or is there a backup plan?

What would you have done if you could have done this from scratch?

@awalterschulze awalterschulze changed the title one home for the WKTs one home for the WKTs (Well Known Types) Aug 21, 2016
@zombiezen
Copy link
Contributor

Adding type aliases is not a hard blocker for moving WKT to one home, but it certainly would help. I mention it to raise awareness of the problems it solves. If we had type aliases, instead of rolling out one breaking change after six months of announcement (as per our new compatibility promise), we could make the announcement and folks could migrate their import paths well ahead of the deadline and not face issues. Both options have their own tradeoffs.

An alternative approach would be to just add the generated protos in go-genproto repo — this would mean they exist in both places. This would be unfortunate because if part of a large codebase uses the type as it exists in go-genproto and another part of a large codebase uses the type as it exists in ptypes, the types would not be interoperable. We've rejected this approach because it's confusing to end-users and the path to resolution is not obvious.

@okdave and I are still thinking about this. If we were starting from scratch, we would have them all in the new go-genproto repository. That is the direction we want to move toward. The implementation plan is still fuzzy at the moment, but we agree it's a problem that should be tackled.

@awalterschulze
Copy link
Author

Interesting. Thanks for you explanation. I really appreciate it :)

I guess I'll still have to make my own fork of gen-proto and then it might as well live in gogoprotobuf/types.

Either way the user of protoc will always have to use a lot of import path remapping with the M parameter. Do you see any way around this in future?

Do you know why the googleapis folder also has to live in go-genproto
It seems like to things that should probably be kept separate?

@dsnet dsnet changed the title one home for the WKTs (Well Known Types) ptypes: one home for the WKTs (Well Known Types) Mar 8, 2018
@dsnet dsnet removed the enhancement label Jul 10, 2019
@dsnet dsnet added this to the v2 release milestone Aug 21, 2019
@dsnet dsnet added post-v2 and removed pending-v2 labels Feb 25, 2020
@dsnet dsnet changed the title ptypes: one home for the WKTs (Well Known Types) types/known: one home for the WKTs (Well Known Types) Mar 3, 2020
@dsnet dsnet removed this from the v2 release milestone Mar 4, 2020
@dsnet
Copy link
Member

dsnet commented May 26, 2020

Fixed with protocolbuffers/protobuf-go@81db48a

@dsnet dsnet closed this as completed May 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants