Remove the legacy .proto. provider

[lberki]

We now have the ProtoInfo provider, which is its modern version.

A flag needs to be added that disables ctx.dep.proto. and all uses need to be migrated to ctx.dep[ProtoInfo].

[ittaiz]

Is ProtoInfo documented? Does it replace also the sources provider?

…

On Wed, 12 Dec 2018 at 17:36 lberki ***@***.***> wrote: We now have the ProtoInfo provider, which is its modern version. A flag needs to be added that disables ctx.dep.proto. and all uses need to be migrated to ctx.dep[ProtoInfo]. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6901>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF6PS3AHpKvBIYBoHXeZgo1u9FUODks5u4SJjgaJpZM4ZProk> .

[lberki]

What's the sources provider? (ProtoSourcesProvider got renamed to ProtoInfo, but it's a class name that should be internal to Bazel)

[ittaiz]

#3701

…

On Thu, 13 Dec 2018 at 9:15 lberki ***@***.***> wrote: What's the sources provider? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6901 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIFwTHDnPxWP0rR500i2lwEsKN5Wg9ks5u4f6cgaJpZM4ZProk> .

[lberki]

[ProtoInfo] is the same provider as .proto indeed. It's even the same implementation and all. Mind you, it's somewhat broken and we should totally fix it some day, but it's broken in the same way as .proto is broken so the migration should consist solely of replacing .proto with [ProtoInfo].

[laurentlb]

Related to #7347

I don't think we should special case .proto. We should have a flag to forbid all the old style providers.

[lberki]

If you are willing to take a step that's that big...

[Bocete]

Are there plans to make ProtoInfo instantiable by users? If so, is there an ETA? Currently, the ProfoInfo constructor isn't callable.

I understand that ProtoInfo has some legacy muck that would be a bit dangerous if exposed to users. But perhaps it could be made work when specifying non-legacy fields only? Maybe that's possible, maybe it isn't; I'm not familiar with the inner workings of that provider.

Thanks! I'd love to contribute to make this happen if you think it's the right thing to do, and you're only strapped for cycles.

[hlopko]

Why do you need to instantiate the provider? That would typically make sense when creating your own iproto_library, and in that case I'd prefer to improve existing proto_library.

[hlopko]

Ah now I see your comment on protocolbuffers/protobuf#6163 (comment). That's a very complicated usecase that I don't understand :)

You write you "suspect" that this will help you, or maybe the Proto sandwich would. I think of sandwich API as not a way to call native.proto_library, but a way to register the same actions as proto_library would. Can you maybe simplify the usecase so I can understand it and maybe we'll come up with a way forward?

[brandjon]

I don't think we should special case .proto. We should have a flag to forbid all the old style providers.

If you are willing to take a step that's that big...

I'd love to remove legacy struct providers this year, not sure whether it'll happen. In the meantime, if a flag helps the proto rules migrate off legacy structs, that's fine; I took the same approach in --incompatible_disallow_legacy_py_provider.

Triaging to the Build API team.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!