-
Notifications
You must be signed in to change notification settings - Fork 5
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
Remove Custom Parser #168
Remove Custom Parser #168
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize this is still a wip and maybe you've changed things already but this caught my eye
8d5926f
to
d55d102
Compare
d55d102
to
67480e8
Compare
… in PR diffs by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems good.
} | ||
EOPROTO | ||
|
||
gen = ProtoBoeuf::CodeGen.new(unit) | ||
klass = Class.new { class_eval(gen.to_ruby) } | ||
|
||
assert_nil(klass::Foo.new.null) | ||
assert_equal(:NULL_VALUE, klass::Foo.new.null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like our parser was basically ignoring this unknown type 🤷
This symbol is consistent with how the other enums work.
246d26b
to
b982b19
Compare
b982b19
to
d426705
Compare
@@ -0,0 +1,104 @@ | |||
// Copyright 2024 Google LLC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused. Why is this a new file while other proto files were already in the repo? I wouldn't expect removing the parser to generate new types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our parser wasn't validating import
statements. Now that our tests are parsing everything with protoc
I had to import this new type to make the SigstoreTest
pass because it's referenced in one of the protos:
import "google/api/field_behavior.proto"; |
I copied this over from here: https://github.com/googleapis/googleapis/blob/master/google/api/field_behavior.proto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found a few Stack Overflows/Google Groups posts about this and it seems cloning the googleapis repo or copying the individual file over is the solution: https://groups.google.com/g/grpc-io/c/iNvCzTF1QxQ
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still not convinced that we should be shipping this file as part of our library. As the Google Groups post mentions, the end-user is responsible for having this file in the "load path" when compiling proto files with protoc
.
Just like how the protobuf
library does not export the googleapis
protos, I don't think we should either.
If the test/conformance process needs it, then we can clone the repo and/or download the file directly to have it included, but I don't think we should have it be a part of lib
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upon reflection, I agree with @paracycle. We should probably figure out what is expected to be built-in and what isn't, and only include what is expected. I think that is only the "well known types", but I haven't done enough research to say for sure.
All rights reserved. They are subject to [this license agreement](https://github.com/protocolbuffers/protobuf/blob/32838e8c2ce88f1c040f5b68c9ac4941fa97fa09/LICENSE). | ||
|
||
The `*.proto` files in `lib/protoboeuf/google/api` are from the [googleapis](https://github.com/googleapis/googleapis) | ||
repository and are Copyright 2024 Google LLC. They are subject to the [Apache 2.0 license](https://github.com/Shopify/protoboeuf/blob/main/contrib/LICENSE.Apache2-0.txt). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This link will be broken until this is merged
We've decided to forgo support for our custom parser in favor of working with binary protobuf files we can get from the
protoc
executable. This PR removes the custom parser code to simplify things. As a consequence of this, our entire test suite now shells out toprotoc
and tests the output from that. We already had a subset of our tests doing this and now they all are. To make this easier,test/helper.rb
definesparse_proto_string
andparse_proto_file
helper methods that can be used throughout our test suite.protoc
is also more strict about protobufimport
statements than our custom parser was. This means I had to import another well-known type,google.api.FieldBehavior
to get ourSigstoreTest
passing. I decided to move our well-known types to a newProtoBoeuf::Google
submodule to keep things a little better organized as well as to makeimport google/*
statements work without having to jump through quite so many hoops.I also added a
.gitattributes
and marked everything inlib/protoboeuf/google/**/*.rb
as generated so it doesn't show up in PR diffs by default. If there's a good reason to have these more visible in PRs I'm happy to undo that.Finally, I added
debug
as a dev dependency in ourGemfile
because I personally find it useful and it's pretty widely used by Ruby developers.I manually tested the executable with the following simple test
proto
file:test.proto3