-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Rework proto generation #1371
Rework proto generation #1371
Conversation
12769fa
to
fdbb9fa
Compare
Not adding a changelog entry for it, as it is nothing visible for users. |
The problem I did have before with some of these things is that the FreeBSD version of a utility is sometimes quite different from the GNU/Linux utility, particularly for command line flags. The reason originally for choosing pax was that it has always been intended to be POSIX compatible across multiple OSes. What problems did you have running it? Using docker for protoc was at the suggestion of some of the other language code contributors (e.g. Yuri from Uber), since it avoids cross-OS issues. Note that the opentelemetry-proto repo makes use of an Otel specific docker image which includes protoc. If we need the gogo plugin, I don't think it would be hard to add it to the docker image as it is built here: https://github.com/open-telemetry/build-tools/blob/e0cdd225af0479836d9418fc25d665d46c16f278/protobuf/README.md Regardless, let me report back on whether this PR works ok on Darwin. |
Yeah, that's painful. I can only hope that wget, rsync and unzip are used in the same way on FreeBSD and Linux.
It complained about the unknown
I'd prefer to avoid using docker for reasons mentioned in the PR message. |
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.
OK, I tried this PR on a Mac, and it works fine except for the missing \
at the end of the shell script lines.
Understood on the more control needed for protobuf generation.
The changes here are: - Fix the default goal (using "default" target is not doing it). - Bail out with a useful message if proto submodule is not checked out. - Replace the use of docker image with downloading the protoc binary and building the gogofast plugin ourselves. This gives us a greater control over the invocation of protoc. - Use rsync to copy the generated code, instead of pax. Pax did not work for me (it was complaining about the unknown -0 flag). The control over the protoc invocation will be useful later, when we will want to generate a code with data structures in one place and the collector code elsewhere. The collector code may or may not depend on gRPC, but data structures have no need for it. This split will happen when we move the gRPC code out of the OTLP exporter module into a submodule. Getting rid of docker has the upside that the generated files do not belong to root, so there is no hassle of changing the ownership of the files, and it is not requires to use sudo for the `clean` target. And not using docker is faster. The downside of this work is that it depends on more tools: rsync, unzip and wget. I can only hope that macOS users have those tools too, and that those tools are invoked the same.
Updated to fix the protogen github workflow (it needs to install different tools now). |
Codecov Report
@@ Coverage Diff @@
## master #1371 +/- ##
======================================
Coverage 77.5% 77.6%
======================================
Files 124 124
Lines 6126 6126
======================================
+ Hits 4753 4755 +2
+ Misses 1122 1120 -2
Partials 251 251
|
The changes here are:
Fix the default goal (using "default" target is not doing it).
Bail out with a useful message if proto submodule is not checked
out.
Replace the use of docker image with downloading the protoc binary
and building the gogofast plugin ourselves. This gives us a greater
control over the invocation of protoc.
Use rsync to copy the generated code, instead of pax. Pax did not
work for me (it was complaining about the unknown -0 flag).
The control over the protoc invocation will be useful later, when we
will want to generate a code with data structures in one place and the
collector code elsewhere. The collector code may or may not depend on
gRPC, but data structures have no need for it. This split will happen
when we move the gRPC code out of the OTLP exporter module into a
submodule.
Getting rid of docker has the upside that the generated files do not
belong to root, so there is no hassle of changing the ownership of the
files, and it is not requires to use sudo for the
clean
target. Andnot using docker is faster.
The downside of this work is that it depends on more tools: rsync,
unzip and wget. I can only hope that macOS users have those tools too,
and that those tools are invoked the same.