mpvScripts.autosub: init at 2021-06-29

[octvs]

Add mpvScripts.autosub, resolves #336986.

Took the discussion over at the linked issue, and other mpvScripts as basis.
Couple of questions to whom might review this:

• There are usage of passthru.updateScript on other scripts, what is the best
  practice for this?
• In a similar manner I saw uses of lib.getExe for dependencies on
  substituteInPlace like here. What is the point of using it rather than a
  direct path?
  • The latter seems more safe (or exact) to me, therefore I opted for using
    it. But I would like to know if there is a best practice and/or the logic
    behind using lib.getExe.

Cheers!

Credits to @jcaesar for supplying an initial version at the discussion

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

---

Add a 👍 reaction to pull requests you find important.

[octvs]

Currently failing test is due to my entry from lib.maintainers missing, which
I expected to be present before this one with this PR already merging.

[AndersonTorres]

What is the point of using it rather than a
direct path?

Encapsulation.
lib.getExe will pick the executable from outputBin. And outputBin can assume different paths according to the derivation, especially in split outputs.

[octvs]

Encapsulation. lib.getExe will pick the executable from `outputBin`. And `outputBin` can assume different paths according to the derivation, especially in split outputs.

Thanks for the kind explanation, I changed it to use `lib.getExe'`.

[octvs]

I've found the answer to the other question here.

[octvs]

Alright, suggestions are applied, thanks for the feedback & explanation!

[jcaesar]

Currently failing test is due to my entry from lib.maintainers missing

Depending on your progress with #354823, you could also cherry-pick the maintainer add commit onto here. It won't cause merge conflicts, and if you rebase either PR after the other is merged, the duplicate commit will silently disappear.

[octvs]

Depending on your progress with #354823, you could also cherry-pick the [maintainer add](0f27402) commit onto here. It won't cause merge conflicts, and if you rebase either PR after the other is merged, the duplicate commit will silently disappear.

Wow, that is great to know. Finally I get to use the `cherry-pick`. Thank you for the kind tip!