python3.pkgs.beets: use fixed-point arguments

[doronbehar]

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.

---

Add a 👍 reaction to pull requests you find important.

[9999years]

Haven't done a thorough review but yay for finalAttrs! Maybe the pluginOverrides attr should be removed? I'd also like to see some more tests here...

[doronbehar]

Maybe the pluginOverrides attr should be removed?

I don't think so. It is still way more comfortable to configure built in plugins via .override and not via .overrideAttrs or .overridePythonAttrs interface. Also that would be a hard API breakage and I'm sure people are using this API.

[doronbehar]

I'd also like to see some more tests here...

I'm down, but testing what?

[9999years]

Looks like this keeps the python3.pkgs.beets hash unchanged, which is a good sign!

I'm a bit nervous about the API for overriding plugins: with this PR, it's still impossible to use the (documented) pluginOverrides argument to override builtin plugins, as well as a whole host of attributes under passthru.plugins:

nix-repl> python3.pkgs.beets.passthru.plugins
{
  all = { ... };
  base = { ... };
  builtins = { ... };
  disabled = { };
  disabledTestPaths = [ ];
  enabled = { ... };
  overrides = { };
  wrapperBins = [ ... ];
}

To me, enabled, overrides, and all seem like reasonable places to put a new plugin, and it's not clear how base and builtins differ ... I'm not sure what a good solution for cleaning these up would be.

Perhaps we can just have a single passthru.plugins attribute and remove the rest? Not sure.

Anyways, I think this PR is a solid improvement over the status quo, but I'd like to get the plugin override API cleaned up soon.

[doronbehar]

I'm a bit nervous about the API for overriding plugins: with this PR, it's still impossible to use the (documented) pluginOverrides argument to override builtin plugins,

Why not? I just added a test that proves it is possible..

as well as a whole host of attributes under passthru.plugins:

I wouldn't say we wish to make it easy to override them all.

To me, enabled, overrides, and all seem like reasonable places to put a new plugin, and it's not clear how base and builtins differ ... I'm not sure what a good solution for cleaning these up would be.

Perhaps we can just have a single passthru.plugins attribute and remove the rest? Not sure.

I agree, it is a remnant from the old implementation. I was thinking of removing them in #452540 but I wanted that PR to be easy to review. I'm open to simplify this but this would be a breaking change and I wish to not do that in this PR.

Addressed in a comment.