Add completion specs for yay and paru AUR helpers

[warp-agent-staging]

Summary

Fixes warpdotdev/warp#5177: yay -S <partial> (and paru -S <partial>) produce no package completions in Warp, unlike pacman -S. Also requested by APP-5382 (Linear).

Root cause: Warp's pacman -S completions come from this repo's own json/pacman.json spec + list_all_packages generator (pacman -Slq), not from shell-native completion. yay/paru have no equivalent spec or generator registered, so they fall back to plain path completion.

This PR is the actual fix. It's referenced from a companion draft PR, warpdotdev/warp#15112, that bumps the warp-command-signatures pin to this branch's head commit, purely so the change can be reviewed/tested end-to-end before this PR merges; that pin must be re-pointed at this PR's merged main commit before warpdotdev/warp#15112 lands.

Changes

• Added json/yay.json and json/paru.json, modeled directly on json/pacman.json. Both cover -U/--upgrade, -D/--database, -Q/--query, -R/--remove, -S/--sync, -T/--deptest, -F/--files, and the shared root options — not just -S — plus each tool's own AUR-related flags (-a/--aur, --repo, yay's -N/--repo).
• Refactored src/generators/pacman.rs to expose its package-list parsing and the installed-package / .pkg.tar-file generators as reusable functions (list_packages, list_installed_packages_generator, list_pkg_tar_files_in_cwd_generator), following the same "one file, multiple *_generators() functions" pattern this repo already uses for apt.rs (apt-get/aptitude) and npm.rs (npm/yarn/pnpm).
• Added src/generators/yay.rs and src/generators/paru.rs, which reuse that shared logic for -Q/-R/-U (installed packages and local .pkg.tar files don't depend on which frontend is used — they always come from the shared pacman database), and register yay_generators()/paru_generators() in generators/mod.rs.

Generator command choice for -S/--sync (the actual bug)

pacman -Slq only lists official repo packages, so reusing it for yay/paru would reproduce the exact reported bug (no AUR completions).

Instead, both yay -Pc (yay --show --complete) and paru -Pc (paru --show --complete) are used. Per each tool's own man page: "Print a list of all AUR and repo packages. This allows shell completion and is not intended to be used directly by the user." This is also exactly what yay's and paru's own bundled bash/zsh completion scripts (_yay_pkg/_paru_pkg) shell out to for the same purpose — so this mirrors upstream's own approach rather than inventing a new one.

Tradeoff considered: the AUR has 100k+ packages, so a live query (e.g. hitting the AUR RPC) on every keystroke would be far too slow for interactive completion. -Pc avoids that by reading from each tool's local, periodically-refreshed completion cache (--completioninterval, default 7 days) instead of re-enumerating the AUR on every call. The cost is that the very first invocation (before any cache exists) can be slow while it's built — every completion after that is fast. This was a deliberate choice, not a blind copy of pacman's command.

Verification

• cargo test --workspace: 141 tests pass, including the repo's own invariants (all_referenced_generators_exist, all_command_specs_succeed_deserialization, all_command_specs_have_no_newlines) — both new JSON specs deserialize correctly and every generatorName they reference resolves to a real generator.
• cargo fmt --all -- --check and cargo clippy --workspace --all-targets -- -D warnings: clean.
• npm run format:check (prettier): clean for the new JSON files.
• Ran the repo's own script/presubmit end-to-end: all green.
• Not exercised: an actual Arch Linux + yay/paru + fish environment, since none was available in the sandbox this was built in. The generator commands (yay -Pc, paru -Pc, pacman -Q) are taken directly from each tool's man page and their own bundled completion scripts, not guessed, but I could not run them against a live pacman/AUR install.

Co-Authored-By: Warp Agent agent@warp.dev

Revision (review findings)

• Added -a/--aur to paru's -T/--deptest, which paru documents as filtering the given package list down to ones that appear in the AUR (-Ta) — the entries covered -T but were missing that flag.
• Added yay_and_paru_bind_list_all_packages_to_their_own_completion_command in src/lib.rs, a regression test that resolves yay's/paru's own dynamic completion data and asserts their list_all_packages generator runs yay -Pc/paru -Pc, not pacman's -Slq. The existing all_referenced_generators_exist test only checks that a referenced generator name exists somewhere in the global union of every command's generators, so it would still pass even if the yay/paru map registrations in generators/mod.rs were dropped entirely (their generator name collides with pacman's). Verified the new test fails with "no dynamic completion data registered for command "yay"" when those registrations are removed, and passes once restored.
• Corrected a doc-comment (and this description, above) that claimed the completion cache refreshes about daily — yay's and paru's own default CompletionInterval/--completioninterval is 7 days.

[warp-agent-staging]

This PR was generated with Warp.

 

[warp-agent-staging]

Closing as a duplicate. This and #334 were opened by the same automated run about 80 seconds apart, both implementing yay/paru completion specs for warpdotdev/warp#5177. #334 is the one that landed (79e45eb), so this branch is now stale against main.

Two defects in what landed — -Pc output parsed as bare package names, and -i/--install modeled under -U instead of -B — are fixed in #336. Nothing has reached users yet: warp still pins warp-command-signatures to 32a7fd5.

Responding as wilson: Open session · View factory task