Import Protobuf types from other packages

[dmdashenkov]

Assuming we have 2 Dart packages.
Package A is a library. It defines Protobuf types and Dart utilities to work with them.
Package B depends on A. It also defines Protobuf types, which depend on types from A.

When trying to build B, we cannot avoid re-generating Dart code for Protobuf types is A. If we don't generate A types again, B types are generated with relative imports for B types and do not compile.
Is there a way to make the plugin use absolute imports and configure the mapping of imported types to the Dart packages which contain them?

[sigurdm]

No, I don't think we support such a thing currently.

Are you in control of both A and B? maybe you could gather all the proto files in a shared package C?

[dmdashenkov]

For us, A is a library and B uses it. We control A but not B.
As the last resort, we have an option of manually substituting import statements. But I was hoping that, maybe, there is already a solution for that.

[sigurdm]

No unfortunately we do not have a thing like that.

How would such an option work? Would it be an option in the .proto file or on the protoc invocation?
I don't think proto imports can have options

[dmdashenkov]

I'd expect there to be a file-level Protobuf option. Something like

option dart_package = 'helpful_library';

Now when generating code, a protoc compiler has access to the descriptor of imported types (through CodeGeneratorRequest.proto_file). So, when generating Dart code it is possible to scan for this option and use a package-based import instead of a path-based one.

Maybe, you'll have a better idea. The main disadvantage of this solution is that it'd require changing the standard library types (or hardcoding them). In general, this works only if the upstream types are declared with the option.

[dmdashenkov]

This is similar to other options such as java_pacakge and go_package.

[sigurdm]

That would work I think - but would have to go into package A.

[sigurdm]

Ah - I read again - you control package A. Then this is the right thing to do.

[sigurdm]

@dmdashenkov would #298 work for your use case?

[dmdashenkov]

Yes, that PR should solve my problem, as far as I can see. Thanks.

[dmdashenkov]

Hi. Any updates on the feature status?

[sigurdm]

Sorry for the silence.
I am trying to get a proper option into protobuf itself. (So you would no longer need to import dart_options) it is taking some time.
Hopefully I'll manage, it seems the right way to go.

[dmdashenkov]

@sigurdm, thanks for the update.
I'd be grateful if there was a channel I could monitor (e.g. a GitHub issue etc.), so you wouldn't have to serve as a data bus). A quick search in protocolbuffers/protobuf didn't give any relevant issue.

[sigurdm]

Sorry - this is currently only tracked on an internal PR.
It would appear as optional string dart_package = 48; in descriptor.proto

[dmdashenkov]

Hi. Are there any updates on this issue?