Remove generated code from repository

[Oberon00]

The generated go code should not be checked in into the repository. See also #77 (comment)

Usually you should generate the files only during the build and maybe publish an artifact with them but never check them into source control (the same way you don't check in binary executables). I see #74 stated reasons to generate the code in this repository, and I think having the build files here is fine. But having the generated code here seems wrong.

[Oberon00]

@tigrannajaryan What were the reasons to include the generated code (as opposed to just the build files required to generate it) anyway?

[tigrannajaryan]

@Oberon00 So that the code can be consumed by other repos that depend on it. This was the approach used by OpenCensus proto and I went with it.

I am not opposed to removing generated code from this repo provided that there is a clear way to consume the proto from dependent projects.

[Oberon00]

Coming from more of a Java background, I would have expected the build in the repository to publish some artifacts to some external repository instead of committing the generated files to version control. Then other repositories would depend on that by referencing the generated artifact.

[Oberon00]

Yet another possibility would be to invoke the build script from the client projects. If it's more than a single line of client build script to do so, tune the proto build so that it becomes just a single line 😄

[jmacd]

We could use Docker with a prebuilt protoc for this task.

…

On Wed, Dec 11, 2019 at 7:27 AM Christian Neumüller < ***@***.***> wrote: Yet another possibility would be to invoke the build script from the client projects. If it's more than a single line of client build script to do so, tune the proto build so that it becomes just a single line 😄 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#79?email_source=notifications&email_token=AA3WFCP3MBAW23AAOUB2LXTQYEBFBA5CNFSM4JTU6ITKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGTQZYA#issuecomment-564595936>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WFCPINR57C6RFWP4UKJLQYEBFBANCNFSM4JTU6ITA> .

[tigrannajaryan]

Docker is also good option. We use this https://hub.docker.com/r/znly/protoc for our internal builds.

[tigrannajaryan]

@open-telemetry/specs-approvers does anybody know how to generate Go ProtoBuf code correctly from a different repo?

Generated Go files import each other and import statements include full URL as specified in go_package option in .proto files. This is currently set to this repository's URL. The net result is that the generated files cannot be compiled because they end up importing non-existing packages.

What is the right way to do this? I was not able to find a protoc option to override import paths. Is one expected to manually alter the import paths after generation (or go_package option before generation)?

@OPEN 원격 분석 / 사양 승인자는 다른 리포지토리에서 Go ProtoBuf 코드를 올바르게 생성하는 방법을 알고 있습니까?

생성된 Go 파일은 서로 가져오고 가져오기 문은 .proto 파일의 옵션에 지정된 전체 URL을 포함합니다. 이 정보는 현재 이 리포지토리의 URL로 설정되어 있습니다. 결과적으로 생성된 파일은 존재하지 않는 패키지를 가져오기 때문에 컴파일할 수 없습니다.go_package

이 작업을 수행하는 올바른 방법은 무엇입니까? 가져오기 경로를 재정의할 수 있는 옵션을 찾을 수 없습니다. 생성 후 가져오기 경로(또는 생성 전 옵션)를 수동으로 변경해야 합니까?protoc``go_package

[nilebox]

Coming from more of a Java background, I would have expected the build in the repository to publish some artifacts to some external repository instead of committing the generated files to version control.

In Go, source code is the artifact, and usually generated code is committed in the "library" repos like this one.

If generated code was only used within this repo, then it could have been generated as part of the build. Third parties shouldn't need to generate code they don't own.

Also, committing generated code makes it easier to review side effects in diff after running gen-go.