protobuf: 24.4 -> 25.3

[GaetanLepage]

Description of changes

• Add protobuf v25.2.
• Set it as the default version (previously v24.4).

Note: I had to manually set the abseil version to a more recent one (202308) instead of the default one (202301).
Maybe it should be consider to bump the default abseil-cpp to a newer version.

Changelog: https://github.com/protocolbuffers/protobuf/releases/tag/v25.2

cc @tobim @jonringer

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[tobim]

I think we should wait until 23.11 is out before doing this update.

Note: I had to manually set the abseil version to a more recent one (202308) instead of the default one (202301).
Maybe it should be consider to bump the default abseil-cpp to a newer version.

Indeed, this pin would result in many packages to have multiple version of abseil in their closures. On paper abseil supports that, but even if it doesn't cause any build failures it would still be a waste of resources, imho.

[GaetanLepage]

I think we should wait until 23.11 is out before doing this update.

Fine by me !

Indeed, this pin would result in many packages to have multiple version of abseil in their closures. On paper abseil supports that, but even if it doesn't cause any build failures it would still be a waste of resources, imho.

The right thing to do would be to bump the default version of abseil to a more recent one right ?

[GaetanLepage]

@tobim in the end I bumped the default abseil version.

[GaetanLepage]

python311Packages.protobuf fails to build with

==================================== ERRORS ====================================
_______________________ ERROR collecting minimal_test.py _______________________
ImportError while importing test module '/build/source/python/minimal_test.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/nix/store/480sm7i0dn11hf0lmx4wl4gk9w1k5s8r-python3-3.11.6/lib/python3.11/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
minimal_test.py:35: in <module>
    from google.protobuf.pyext import _message
E   ImportError: cannot import name '_message' from 'google.protobuf.pyext' (/build/source/python/google/protobuf/pyext/__init__.py)

[GaetanLepage]

python311Packages.protobuf fails to build with

protocolbuffers/protobuf#14880 (comment)

[de11n]

It would be more convenient if we could add protobuf3_25 without bumping the default so that folks don't have to wait to use it.

[de11n]

It would be more convenient if we could add protobuf3_25 without bumping the default so that folks don't have to wait to use it.

Thank you! C.f. #272493

[SomeoneSerge]

So the README says that

• the cpp (.../pyext) backend is "legacy" and advises to use the μpb backend,
• mentions that

  While upb offers a C API, the C API & ABI are not stable. For this reason, upb is not generally offered as a C library for direct consumption, and there are no releases. https://github.com/protocolbuffers/protobuf/tree/main/upb

Did we ever have any ABI compatibility guarantees with cpp? I'm wondering if we could do any tricks for tensorflow like build it with the older protobuf but link the newer one, and also maybe use nixpkgs-pytools to rename its references to the old protobuf python module? (only relevant until we update tf to 2.15?)

[GaetanLepage]

@ofborg build protobuf.tests

[SomeoneSerge]

I think it's safe to merge now. This won't go into the release but into the unstable

[SomeoneSerge]

RE: ofborg

Hypothesis doesn't depend on protobuf and so is broken independently:

❯ nix path-info --recursive --derivation nixpkgs#python311Packages.hypothesis | grep protobuf
~