4 ms·
It reminds me of why the protobuf compiler had never received any functionality regarding the generation of python code with the redefined library roots [1]: Go
by heavenlyblue 9y ago
It reminds me of why the protobuf compiler had never received any functionality regarding the generation of python code with the redefined library roots [1]: Google has a monorepo, therefore they never needed this. It is especially amusing when it is later being explained [2]:
> Overall, your directory structure appears to be more complicated
> than what we generally do at Google (which is the environment where
> all this behavior was designed/evolved). At Google we generally have
> a single directory structure for all source files, including protos.
Well, yes. You do... At Google.
[1] https://github.com/google/protobuf/issues/881 https://github.com/google/protobuf/issues/881
[2] https://github.com/google/protobuf/issues/1491 https://github.com/google/protobuf/issues/1491
- haberman 9y agoHi there, those are my words you quoted above. I just wanted to emphasize that we would help open-source users out on this if we could. This isn't a case of "we didn't need it, so we never implemented it." The problem is that no one has proposed a solution that is compatible with our need to do parallel compilation inside Google. The only proposal I saw involved removing the 1:1 file correspondence between .proto input and _pb2.py output. I can understand why people would want this. But inside Google, we compile all our .proto files in parallel, and our whole build system depends on being able to parallelize things in this way. If you have a solution to this problem that doesn't break any of our existing use cases, we're all ears.