anki: don't vendor Python dependencies

[dotlambda]

see #425219 (review)

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[eljamm]

Although I understand what this PR attempts to achieve and why, merging it as-is breaks Anki, which isn't good. Unless you're also willing to do the Python package-set migration yourself, I suggest creating an issue, instead, for better discussion and coordination with maintainers.

[dotlambda]

I'm not willing to wait very long before merging this even though it breaks anki; that's why it's a PR rather than an issue.

[eljamm]

That's exactly what I was concerned about. The damage has already been done, so breaking Anki will only hurt users and make maintainers' job harder. I kindly ask that you at least give the latter some time to reply, first. This said, I'm also willing to look into this in my free time this week.

[euank]

I definitely don't think we should merge this and intentionally break users unless we have a stronger reason than "this isn't idiomatic", i.e. unless this is specifically blocking some other PR or effort.
Is this issue blocking other important changes or efforts? Is there more context for the urgency?

It does appear that naively swapping in the nixpkgs versions of all the python dependencies does end up with a working anki binary, though I'm not sure if there's any more subtle breakages in functionality

euank@98aa335

I s'pose the pragmatic thing is to go with that (though I'm sure there's a more pragmatic way to relax the dependency versions, I guess pythonRelaxDepsHook probably works here).

Ignorable rambling

... It's neither here nor there, but it does seem a bit inconsistent that we've ended up with such different norms for different package ecosystems within nixpkgs, like the yarn and rust portions of the anki packaging both use the versions specified by the upstream lockfiles because that's idiomatic in nixpkgs for both of them (`rustPlatform.fetchCargoVendor` and `yarn-berry.fetchYarnBerryDeps` are both idiomatic enough, and both stick to the application's versions of dependencies), while for python and C we're doing the normal linux-distro thing of encouraging single system-wide versions of each dependency.

For C, we're kinda forced for some dependencies, like libmesa and such need to match so graphics work, and similar for GTK and QT libraries.

For python, other linux-distros are forced to minimize package versions because there's a global site-packages, but nix doesn't have that constraint, we can do whatever we want.

I get that it's nice to have a smaller nix store, that it's nice to be able to patch a bug in a library in one place, and have it be fixed for more applications total, so there's definitely strong points for minimizing package versions and preferring the nixpkgs versions....

But on the reverse side, upstream has tested one set of python packages, just like they've tested one set of node-packages and rust packages, and they've clearly noted down those versions in a lock-file. We're signing ourselves up for more involved maintenance work for a package by diverging from upstream's versions.

.... I don't really have any strong point here, just that it seems like nixpkgs has picked opposite approaches for different language ecosystems.