feat: Remove and redirect py_proto_library to protobuf

[comius]

Protobuf team is taking ownership of py_proto_library and the implementation was moved to protobuf repository.

Remove py_proto_library from rules_python, to prevent divergent implementations.

Make a redirect with a deprecation warning, so that this doesn't break any users.

Previously this was attempted in: d0e25cf

Work towards #2173, #2543

[rickeylev]

This looks almost the same as something Ignas drafted up a couple weeks ago: #2581

(I don't have a preference for either PR, to be clear)

The main difference seems to be this PR leaves protobuf at 29.0-rc2, while the other PR raises protobuf to 29.3. Both seem to have passing tests, though? @aignas @comius

It's not clear to me -- should we raise the version in our module or not?

This PR also mentions that protobuf 30.0 is needed for a certain test to pass? Curiously, the other PR deletes that test ("external_import_test"). Should we raise protobuf to 30.0?

cc @tpudlik who responded to a question on the other PR. Something about waiting for a certain bug to be fixed in protobuf?

I'm happy this is looking eminent!

[aignas]

Sorry, did not have time to finish my PR. My TODO was

• add a patch to be able to pass all the tests or wait until the next release of proto.
• undo the change removing the extra test
• undo the version change

I think my preference moving forward would be:

• keep all of the tests in bzlmod folder.
• rules_python depends on the same proto library version, but we note that users may want to update their protobuf library to 30 for compatibility.
• I was thinking to add the deprecation using our helpers because this API will have to be there until v2 which means bazel 9.

Thanks for the PR!

[comius]

I need to provide some more context.
protobuf release 30-rc1, has some failures, becuase 2 different py_proto_libraries can't be used - aspects cause action conflicts. Thus, it would be nice to be able to point this py_proto_library to protobuf, before protobuf 30 is cut. But that requirese this PR and another release of rules_python.

The test that I disabled is fixed in protobuf 30 with protocolbuffers/protobuf#20193
Once Protobuf is updated to 30., it maybe reenabled here. But we should probably be moving those tests into Protobuf anyway.

[aignas]

Does that mean that users may need to do overrides for things to work when upgrading to version 30? I am struggling to understand the impact of the rollout/release of a new vecsion of rules_python here.

We plan to release rules_python soon.

[comius]

Does that mean that users may need to do overrides for things to work when upgrading to version 30? I am struggling to understand the impact of the rollout/release of a new vecsion of rules_python here.

What do you mean with overrides? Versioning? I don't think any manual interaction is needed by the users, except:

If using Bzlmod, Protobuf 30 will depend on the newly released rules_python, which will lead to a single py_proto_library. WORKSPACE users will need to upgrade by hand.

[aignas]

I need to provide some more context.
protobuf release 30-rc1, has some failures, becuase 2 different py_proto_libraries can't be used - aspects cause action conflicts.

This was part of the message which I did not fully understand at first. I thought that it was about something that would require our users to do extra things when upgrading protobuf library versions.