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

feat: export package version #866

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

feat: export package version #866

wants to merge 1 commit into from

Conversation

alexander-fenster
Copy link
Contributor

Since we are entering a phase when different client libraries will use different gRPC implementations (most will be migrated to @grpc/grpc-js but some will still stay with grpc), we'd like to have an easy way for the client library to set the gRPC version in the headers without actually knowing if the grpc instance they work with is a C-core or JS implementation.

Can we have this grpc.version added to both implementations to make this tracking easier? (or feel free to suggest another options!)

@murgatroid99
Copy link
Member

First, both libraries put some variant of this information in the user-agent header, or at least they're supposed to. Does that resolve your problem of wanting that information in a header?

Second, library users can already do require('grpc/package.json') or require('@grpc/grpc-js/package.json') and then format the information from that however they want.

@alexander-fenster
Copy link
Contributor Author

Libraries use grpc/${version} header. @JustinBeckwith can know more about tracking and if user-agent header is sufficient. Justin, do you know if can we go with user-agent and not set grpc at all?

As for the second item, it won't be possible since the gax code can accept any grpc instance from the caller and it does not know if it's one or another implementation.

@murgatroid99
Copy link
Member

If the current user-agent behavior does not solve your problem, this change needs to go through our API design review process because it is a (non-breaking) API change.

@murgatroid99
Copy link
Member

I don't think it's a good idea to export this information pre-formatted for a specific use-case. I would prefer to either export the whole package.json as a single object or export name and version verbatim.

@alexander-fenster
Copy link
Contributor Author

I'm totally fine with either of those options - I just wanted to have the conversation started :)

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

Successfully merging this pull request may close these issues.

2 participants