kodiPackages.sendtokodi: 0.9.924 -> 0.10.0

[zibaone]

Note: this PR replaces #570301, which could not be re-opened — the amend adding the Assisted-by: trailer (required by the AI policy) rewrote the head, and GitHub permanently refuses to re-open a closed PR whose branch was force-pushed. The revision is unchanged (identical tree); the full context is in #570301.

Apologies for the initial submission not following the PR template. Thanks @RossSmyth and @aanderse for the guidance — the description below now follows the template, and the guidelines (incl. the automation/AI policy) have been reviewed.

sendtokodi v0.10.0 re-architected the add-on around yt-dlp and added a system yt-dlp source: instead of vendoring yt-dlp, the add-on can now import a distribution-provided yt_dlp. This PR wires the packaged yt-dlp into that source.

The packaged 0.9.924 predates this rework: its patches no longer apply and it can no longer resolve many sites.

Changes

• Bump to v0.10.0; drop the obsolete use-yt-dlp-only.patch.
• Wire the system source: expose the packaged yt-dlp and its challenge-solver scripts (yt-dlp-ejs) as lib/yt_dlp / lib/yt_dlp_ejs with passthru.pythonPath = "lib" (the script.module.* mechanism).
• Default ytdlp_source = "system" and deno_autodownload = false so the defaults work with no runtime downloads (the packaged yt-dlp carries the solver scripts and a baked-in Deno path, see yt-dlp: make deno available to python dependents #466381). Both are plain settings values, easy to flip if you prefer the upstream defaults.
• Add passthru.updateScript via nix-update (addonUpdateScript does not apply: the add-on is not distributed through mirrors.kodi.tv).

Testing (x86_64-linux)

• kodiPackages.sendtokodi builds; lib/yt_dlp / lib/yt_dlp_ejs point at the packaged yt-dlp / solver.
• kodi.withPackages (p: [ p.sendtokodi p.inputstream-adaptive ]), headless end-to-end (no Deno on PATH; the packaged yt-dlp provides its own Deno): resolves with the packaged yt-dlp — Using system yt-dlp 2026.08.19 — and plays (DASH 1080p, streams 137+140), with no runtime downloads.
• For DASH streams, install kodiPackages.inputstream-adaptive alongside.
• Also exercised interactively on a live desktop session (windowed Kodi 21.3, same package, PipeWire audio): the settings dialog shows the new defaults (yt-dlp source: system; Deno auto-update off, "Installed Deno version: not installed"), and playback works end-to-end with audio, including a full play-through to end-of-stream.
• nixpkgs-review pr 570301 (x86_64-linux): 1 package built — kodiPackages.sendtokodi (evaluated via kodiPackages.sendtokodi: 0.9.924 -> 0.10.0 #570301's CI eval; same tree as this PR).

References

• Upstream system source: sendtokodi PR #185 / PR #186 (by @zibaone).
• Deno was resolved centrally in yt-dlp: kodiPackages.sendtokodi: Add deno to PATH for YouTube JS challenges #466006 → yt-dlp: make deno available to python dependents #466381 (baked-in Deno path; kodiPackages.sendtokodi: add deno to the kodi PATH #466014 rejected).
• Upstream changes since 0.9.924: compare v0.9.924...v0.10.0.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • 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/. (Kodi add-on: no such binary files; runtime was exercised by the end-to-end tests above.)
• 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.
• Follows the automation/AI policy.

Automation/AI disclosure

Per the automation/AI policy: this change — package file, commit message and this description — was developed with the assistance of an LLM-based tool (Hermes Agent, primary model deepseek-v4.1-flash). It was reviewed, tested and is submitted by me (@zibaone), who is responsible for it and can answer questions about it. Testing was scripted (headless Kodi, driven over JSON-RPC) and reproducible; scripts available on request. The commit carries an Assisted-by: trailer.

[Mynacol]

Some review comments I made while reading the PR code.

[Mynacol]

Unnecessary comment

[zibaone]

100% agreed

[Mynacol]

Do we have to use symlinks for this? Can't we just add this into buildInputs, dependencies or similar and the nixpkgs infrastructure makes it available to this python?

[zibaone]

I'm not really sure, see the comment below for details. from my window, we must, but I'd like to know your point of view.

[Mynacol]

Use a xml modification program like yq-go to avoid having to regex your way through structured formats.

[zibaone]

you're right, thanks, it's done :)

[Mynacol]

This might not be needed anymore based on my earlier suggestions.

[zibaone]

depends on your 2nd comment, see below for details

[zibaone]

Thanks for the review — and sorry for the slow reply.

default.nix:24 (unnecessary comment). Agreed — removed in the updated revision.

default.nix:57 (symlinks instead of buildInputs). This is the point we were least sure about, so we looked into it rather than guess. What we can observe:

• pkgs/applications/video/kodi/wrapper.nix assembles Kodi's PYTHONPATH from exactly two things: requiredPythonPath (a fixed pillow + pycryptodome from kodi.pythonPackages) and additionalPythonPath, which is "${addon}${addonDir}/${addon.namespace}/${addon.pythonPath}" for each add-on exposing passthru.pythonPath — a path inside the add-on output.
• requiredKodiAddons in pkgs/top-level/kodi-packages.nix keeps only add-ons (hasKodiAddon), so a Python derivation placed in buildInputs/propagatedBuildInputs is dropped before either of those lists is built.
• We also tried Kodi itself, with a test add-on that has a lib/ of its own and declares <extension point="xbmc.python.module" library="lib" />: Kodi does not add that directory to the interpreter it runs the add-on in (sys.path starts with the add-on root, no lib/). It does add it for add-ons that depend on such an add-on.

In other words, every route we could find ends with the module living inside an add-on's own file tree — which is why yt_dlp/yt_dlp_ejs are materialised under lib/.

For context, the symlink itself is not new here: #420504 introduced it for this add-on in 0.9.924, on SuperSandro2000's review suggestion to symlink rather than copy. It worked then because service.py appended its own lib/ to sys.path (sys.path.append(os.path.join(dir_path, 'lib'))), and 0.10.0 removed both the bundled module and that append — core/ytdlp_manager.py now states that the location "is a packaging concern: the addon only asks whether it can be imported. Nothing is added to sys.path here." That is why passthru.pythonPath was added in this update.

default.nix:62 (yq-go instead of regex). Agreed, adopted: the defaults are now set with yq -p=xml -o=xml and read back afterwards (yq -o=json -r), so a default that does not land fails the build instead of passing silently. We compared the result with the previous sed output: semantically identical (the XML tool only reindents the file).

default.nix:67 (passthru.pythonPath possibly unnecessary). We believe it is still needed: the add-on imports yt_dlp itself, and pythonPath is the only thing that puts its lib/ on PYTHONPATH. Kodi itself never adds an add-on's own lib/ directory (see above).

We may well be wrong about the symlink and pythonPath — and we would rather be told so than keep something we cannot justify. If you have a mechanism in mind that makes either unnecessary, we would be glad to hear it and happy to rework the PR accordingly.

Disclosure (automation/AI policy): this reply was prepared with the assistance of an LLM tool — Hermes Agent, primary model deepseek-v4.1-flash — and reviewed, verified and posted by me.