rapidfuzz-cpp: add passthru.tests.levenshtein

[bryango]

As suggested by @dotlambda in #283726 (comment).

Description of changes

python3Packages.levenshtein crucially depends on rapidfuzz-cpp, so we add it to passthru.tests to prevent future breakage. The patch is targeted at master, as it should not cause any rebuild when the former staging-next is fully cached.

ofborg all green: https://github.com/NixOS/nixpkgs/pull/283915/checks?check_run_id=20887684631

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/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 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.

---

Add a 👍 reaction to pull requests you find important.

[illustris]

Not a blocker for merging, but it might better to do

passthru.tests.levenshtein = python3Packages.levenshtein.override {
  rapidfuzz-cpp = finalAttrs.finalPackage;
};

[dotlambda]

it might better to do

passthru.tests.levenshtein = python3Packages.levenshtein.override {
  rapidfuzz-cpp = finalAttrs.finalPackage;
};

Why so? Isn't the point to test the python3Packages.levenshtein package? If that ends up eventually overriding rapidfuzz-cpp but still builds, that's fine too.
I would just do

passthru.tests = {
  inherit (python3Packages) levenshtein;
};

[bryango]

I would just do

passthru.tests = {
  inherit (python3Packages) levenshtein;
};

I am okay with either. I have simply reverted the last commit and now the code is equivalent to the suggestion here, albeit less idiomatic.

[bryango]

Done! Tested locally, looks good! @dotlambda

[illustris]

it might better to do

passthru.tests.levenshtein = python3Packages.levenshtein.override {
  rapidfuzz-cpp = finalAttrs.finalPackage;
};

Why so? Isn't the point to test the python3Packages.levenshtein package? If that ends up eventually overriding rapidfuzz-cpp but still builds, that's fine too. I would just do

passthru.tests = {
  inherit (python3Packages) levenshtein;
};

Depends on what you're trying to test. If you are just trying to test whether python3Packages.levenshtein builds with the default version of rapidfuzz-cpp, that is sufficient. Instead, if you want to test whether a modified version of the package, let's say with some patches (applied to it with overrideAttrs), would break python3Packages.levenshtein, this wouldn't be enough. The way it is now (with finalPackage), it can test both. passthru.tests.levenshtein = python3Packages.levenshtein; is less useful as a test than python3Packages.levenshtein.override {rapidfuzz-cpp = finalAttrs.finalPackage;};.

That being said, going back and forth on this change isn't worth blocking this PR. It can be merged with either version.