--descriptor_set_out without --include_imports or code generation should not fail with missing import files

[anuraaga]

What version of protobuf and what language are you using? Version: 3.21.2 Language: None

What operating system (Linux, Windows, ...) and version?

Mac OS X

What runtime / compiler are you using (e.g., python version or gcc version)

What did you do?

Proto file with imports, e.g.

import "google/api/annotations.proto";
import "google/api/field_behavior.proto";
import "google/protobuf/empty.proto";
import "google/protobuf/timestamp.proto";
import "validate/validate.proto";

protoc -odescriptors.pb hello.proto

What did you expect to see

Build succeeds to generate the descriptor for the input proto

What did you see instead?

Build fails with missing includes

import "google/api/annotations.proto";
import "google/api/field_behavior.proto";
import "google/protobuf/empty.proto";
import "google/protobuf/timestamp.proto";
import "validate/validate.proto";

I am trying to use protoc to generate machine parsable descriptors from arbitrary proto files where imports are not available. For context, I want to process the proto files in Go code. Because I am not specifying --include_imports, there doesn't seem to be a reason that this would fail as the descriptor should just be a transformation of the source file with no added semantics (e.g. loading imports).

[acozzette]

I think this could potentially be a useful feature to have, but we do need at least one level of imports to be able to interpret the source file. Given an identifier X, we often need to process the imports to determine whether X is an enum or a message.

[kylepapili]

Agree that this would be an incredibly useful feature. Thank you for the explanation @acozzette but I am curious if a "best-available-info" descriptor could be generated?

So any objects reliant on imports would just have an unknown type?

I think there is great value in this functionality if it seems feasible.

[acozzette]

This functionality already exists to a certain extent through DescriptorPool::AllowUnknownDependencies. Currently there is no flag that will make protoc call that method, but it would be easy to tweak protoc to do that just for the purpose of experimentation. I have thought about doing this in the past because it could make our build system more efficient. We could potentially speed up builds a bit if we didn't have to rebuild a proto's descriptors every time a transitive .proto dependency changes.

[kylepapili]

I wasn't aware of DescriptorPool::AllowUnknownDependencies, that definitely should be a fairly straight forward modification to protoc. We have a few workflows that would benefit greatly from this capability as well and I imagine many others do too.

[kylepapili]

No updates on this? @acozzette

[acozzette]

No, we are not actively working on this but would be willing to review pull requests.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.