py-protobuf3: update to 5.29.3, remove py27 and py38 subports #27351
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@mascguy This is a draft. I’m putting it here for discussion.
protobuf3-cpp and py-protobuf3 are currently at version 21.12 (2022-12-12). The current py-protobuf3 port uses the pure-Python implementation. There is a upb implementation that offers better performance with the same interface, and this pull request began as an attempt to migrate to upb.
I’m not sure what reasons may have previously existed to keep protobuf3-cpp and py-protobuf3 in version lock, but I believe that py-protobuf3 is fully independent of protobuf3-cpp at 29.3, the new version proposed here. That said, it would certainly be better to not have to hold protobuf3-cpp back, and I see that there’s a more recent protobuf3-cpp-upstream at 29.2. Can you help understand what the current situation with protobuf3 versions is?
This pull request removes the py27 and py38 subports from py-protobuf3. The py38 one appears unused as far as I can tell. The py27 one has a few references from things like caffe+python27, but that port also depends on py27-numpy and py27-scipy which are gone, so removing py27-protobuf3 shouldn’t be breaking. On the other hand, ola+python27 (in its default_variants) would appear to break if py27-protobuf3 disappeared. I could certainly restore the py27 variant at protobuf 17.3 if desired, but I thought I’d save myself the trouble until we could talk about whether this is even a feasible direction forward, or if there’s a reason to continue holding py-protobuf3 back to 21.12.
What are your thoughts?
Description
Type(s)
Tested on
macOS 15.2 24C101 arm64
Xcode 16.2 16C5032a
Verification
Have you
port lint
?sudo port test
?sudo port -vst install
?