Fix yay/paru completion specs: -Pc field separators and -B/--build option placement - #336
Conversation
Addresses review feedback on #334: 1. Critical: `yay -Pc` / `paru -Pc` output is not bare package names. yay writes tab-separated `name\tsource` lines (createAURList/ createRepoList in pkg/completion/completion.go); paru writes space-separated `name source` lines (repo_list/pkgbuild_list/ aur_list in src/completion.rs), where `source` is `AUR` or the repository name. The previous generator treated the whole line as the insertable package name, so completing `yay -S btrfs-` would have inserted "btrfs-progs\tAUR" literally. Replaced the naive per-line Suggestion with a `parse_package_list` function per tool that splits on the correct separator, uses the first field as the insertable name and the second field (AUR/repo name) as the description, and degrades gracefully (skips blank/ nameless lines, keeps a bare name with no description) on malformed input instead of panicking or inserting garbage. Added unit tests in yay_tests.rs / paru_tests.rs covering AUR lines, repo lines, single-field lines, blank lines, and empty output. Verified against real output: built yay-bin and paru from AUR in an Arch Linux container and captured actual `-Pc` output, which matches the upstream source exactly (e.g. `0ad-boongui\tAUR` for yay, `acl core` for paru). 2. `-i`/`--install` was modeled on `-U`/`--upgrade`, which doesn't accept it; it's a `-B`/`--build` option (yay: "BUILD OPTIONS (APPLY TO -B AND --build): -i, --install"; paru: "Build specific options: -i --install"). Removed it from `-U`/`--upgrade` in both specs. yay.json already had `-B`/`--build`; added `-i`/`--install` to it. paru.json had no `-B`/`--build` operation at all even though it's documented in paru's own --help ("paru {-B --build} [dir(s)]"); added it with a folder-completed variadic arg and `-i`/`--install`. Co-Authored-By: Warp Agent <agent@warp.dev>
There was a problem hiding this comment.
Overview
Corrects the -Pc output parsing and the -i/--install operation placement that landed in #334, with the parser now validated against real yay/paru output. Two items need a human decision rather than a code change.
Concerns
- This repo's
add-command-specguidance states a completion-dropdown screenshot for each generator is required and that work is not accepted without it, and this PR has none: the environment has no GUI/computer-use access, so no live Warp session was driven. The parser is verified against real-Pcoutput captured fromyayandparubuilt in anarchlinuxcontainer, which covers the defect this PR fixes but is not the required end-to-end proof. Either waive the requirement for this follow-up or have someone on an Arch host confirmyay -S <prefix>andparu -S <prefix>in Warp before merge. paru.jsonwas largely derived from paru's shipped fish completion script, and current paru has drifted from it:-N/--repois replaced by a bare--repo,--mode,--pkgbuilds, and-xare new, and-L/--repoctland-C/--chrootctlno longer appear in the CLI. This PR deliberately does not reconcile that, so some paru completions will describe an older CLI surface. Decide whether that is acceptable to ship or should block on a separate pass overparu.json.
Verdict
Checks: build pass, tests pass (153), CI green (Analyze (rust) still pending), visual proof missing
Found: 0 critical, 0 important, 0 suggestions, 0 nits, 2 questions
Responding as wilson: Open session · View factory task
|
@warp-agent-staging[bot] I'm starting a first review of this pull request. You can follow along in the session on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR fixes the yay/paru completion specs by parsing -Pc output into package-name suggestions with source descriptions, moves -i/--install out of upgrade operations, and adds/updates build operations where appropriate. The new unit tests cover normal AUR/repo output, single-field fallback, blank lines, and empty output for both parsers.
Concerns
- No blocking concerns found. No approved or repository spec context was provided, and the supplemental security pass did not identify security findings in the changed generator/spec code.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
Matches the repo's dominant convention (git.rs, ip.rs, npm.rs, kubectl.rs, and 8 others use inline #[cfg(test)] mod tests; only 3 generators use a separate file). Moves the contents of yay_tests.rs and paru_tests.rs into inline mod tests blocks at the bottom of yay.rs/paru.rs, deletes both _tests.rs files. Same cases, same assertions, no coverage dropped. Co-Authored-By: Warp Agent <agent@warp.dev>
Merged PRs: - Fix nx run completions: use nx graph --file=stdout (warpdotdev/command-signatures#335) - Add completion specs for yay and paru (AUR helpers) (warpdotdev/command-signatures#334) - Fix yay/paru completion specs: -Pc field separators and -B/--build option placement (warpdotdev/command-signatures#336) - Forward --context/--cluster/--user in kubectl generators (warpdotdev/command-signatures#331) The kubectl change forwards a --context, --cluster or --user written on the command line into the commands the completion generators run. Without it, completions after a --context enumerated from the shell's active context instead of the one on the line (#5186, #3929). It also adds --user value completions and wires --context/--cluster/--user up for kubecolor and oc. Co-Authored-By: Warp Agent <agent@warp.dev>
…--cluster/--user forwarding) (#15109) ## Description Updates `warp-command-signatures` to `15debaeb`, the squash commit on `command-signatures:main` for warpdotdev/command-signatures#331. That PR fixes the last remaining symptom of #5186: a `--context` (or `--cluster`, or `--user`) written on the command line was never forwarded into the commands the kubectl completion generators run, so later completions enumerated from the shell's active context instead of the one on the line. With `kubectl --context staging-cluster --namespace <TAB>`, the generator ran `kubectl … get namespace -o custom-columns=:.metadata.name` with no `--context`. It now forwards `--context`, `--cluster` and `--user`, mirroring the existing `--kubeconfig` and `--namespace` handling. It also adds value completion for `kubectl --user`, and wires `--context`/`--cluster`/`--user` up for `kubecolor` and `oc`, which declared those options with no generator. ### Merged PRs - Fix nx run completions: use nx graph --file=stdout (warpdotdev/command-signatures#335) - Add completion specs for yay and paru (AUR helpers) (warpdotdev/command-signatures#334) - Fix yay/paru completion specs: -Pc field separators and -B/--build option placement (warpdotdev/command-signatures#336) - Forward --context/--cluster/--user in kubectl generators (warpdotdev/command-signatures#331) ## Linked Issue Addresses #5186 (labeled `ready-to-implement`). Also addresses #3929, which asks for this same context-forwarding behavior. Deliberately no closing keyword — #5186 covers several symptoms and should be closed manually with a note that the earlier parts landed in the June 2026 stable builds. - [x] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). ## Testing The kubectl behavior is covered by unit tests in warpdotdev/command-signatures#331, which assert the generated command string rather than merely that completion happens — including an `assert_eq` on the entire command for the reported case, and a tightened `test_context_and_namespace_flags_before_subcommand` (it previously passed a `--context` but only checked namespace forwarding, which is why the earlier #247 fix missed this). That repo's `./script/presubmit` and CI were green on merge: 174 tests, 33 of them kubectl-specific. For this dependency bump: - `cargo fmt --all --check` passes. - `cargo clippy -p warp_completer --all-targets --tests -- -D warnings` passes against the new rev. - `cargo metadata --locked` accepts the lockfile, so `Cargo.lock` is in sync; the lockfile diff is limited to the two `command-signatures` source lines. - `cargo tree -p warp_completer -i warp-command-signatures` confirms `15debaeb` is what resolves. - `cargo test -p warp_completer` reports 138 passed / 25 failed, identical to `origin/master` with this change stashed. Those 25 failures are pre-existing in this environment and unrelated to the bump. There are no kubectl-specific tests in `warp_completer`. - [ ] I have manually tested my changes locally with `./script/run` ### Screenshots / Videos No capture taken. Exercising this path in a running client requires a full client build against the bumped rev, which is expensive relative to the value: warpdotdev/command-signatures#247 already carries screenshots of the `--context`/`--cluster` value completion working, #331 carries end-to-end evidence from real `kubectl` runs against a synthetic offline kubeconfig, and the generated command is asserted precisely by unit tests. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode <!-- ## Changelog Entries for Stable --> CHANGELOG-IMPROVEMENT: Added completions for `yay` and `paru`, and `kubectl --user` value completions. CHANGELOG-BUG-FIX: Fixed `kubectl` completions ignoring a `--context`, `--cluster` or `--user` written on the command line, so namespaces, pods and other resources are now suggested from that cluster instead of the shell's active context. `kubecolor` and `oc` now complete those flags too, and `nx run` completions were fixed. <!-- warp:pr-description-artifacts start --> <!-- warp:pr-description-artifacts end --> Co-authored-by: Warp Agent <agent@warp.dev>
Summary
Follow-up to #334 (merged as
79e45eb), which added completion specs foryayandparu(fixing warpdotdev/warp#5177) but had two defects caught in post-merge review. This PR fixes them on top of currentmain.Do not bump the
warp-command-signaturesrev pin inwarpdotdev/warp/Cargo.tomlpast this PR. #334's parser bug is onmainright now but hasn't reached any user yet, becausewarp'sCargo.tomlis still pinned to the older rev32a7fd5. This fix needs to land before that pin is bumped, or the first bump will ship the tab/space-separator bug described below.Changes
1. Critical:
-Pcoutput is not bare package namesNeither
yay -Pcnorparu -Pcprint bare package names, and they don't even share a separator:name\tsourcelines (pkg/completion/completion.go'screateAURList/createRepoList:pkgName+"\tAUR\n",pkg.Name()+"\t"+pkg.DB().Name()+"\n").name sourcelines (src/completion.rs'srepo_list/pkgbuild_list/aur_list:name,b" ",db.name(),b"\n", andline,b" AUR\n").The merged version treated each whole line as the insertable package name, so completing
yay -S btrfs-would have insertedbtrfs-progs\tAURliterally — worse than the original bug.Added a
parse_package_listfunction per generator that splits on the correct separator, uses the first field as the insertable suggestion name and the second field (AUR/repo name) as the description, and degrades gracefully (keeps a bare-name suggestion, doesn't panic or emit garbage) on blank or single-field lines. Covered by newyay_tests.rs/paru_tests.rswith AUR-line, repo-line, single-field-line, blank-line, and empty-output cases.Verified against real output, not just source reading: installed Docker and built
yay-binandparufrom AUR inside anarchlinux:latestcontainer to capture actual-Pcoutput:yay -Pc(132,697 lines):02engine-bin\tAUR,0ad-boongui\tAUR,0ad-git\tAUR, ... — confirms the tab-separated format.paru -Pc(17,158 lines):acl core,amd-ucode core,archlinux-keyring core,attr core, ... — confirms the space-separated repo-package format. The AUR portion of this particular run came back with some non-UTF8/garbled bytes (looks like a flaky AURpackages.gzfetch/decode inside the sandboxed container — paru's own cache-refresh path), rather than a cleanname AURsample. I didn't chase this further: it reproduces independently of this change, and the space-separated repo-package format — paru's always-present, dominant case — is already directly confirmed both in real output and in source.I also re-swept every other generator this change touches for the same "right command, wrong output shape" mistake:
list_installed_packagesandlist_all_pkg_tar_files_in_cwdare unchanged logic moved from the pre-existingpacman.rs(not new parsing), so there was nothing new to re-verify there.2.
-i/--installwas modeled on the wrong operationBoth specs had
-i/--installunder-U/--upgrade, which doesn't accept it. It's documented as a-B/--buildoption in both tools:src/help.rs: "Build specific options: -i --install — Install package as well as building."Removed
-i/--installfrom-U/--upgradein bothyay.jsonandparu.json. Added it to yay's existing-B/--buildentries.paru.jsonhad no-B/--buildoperation at all, even though it's documented in paru's own--help(paru {-B --build} [dir(s)]) — added it with a folder-templated variadic arg and-i/--install.3. End-to-end proof
No GitHub PR review threads exist to reply to on #334 (checked via the API) — the review that caught these issues happened out-of-band, not as GitHub comments.
I don't have computer-use/GUI access in this environment, so I could not build and drive a live Warp session to capture the completions-dropdown screenshot this repo's
add-command-spec/test-local-warpskills ask for. Stating that plainly rather than approximating it. Everything else — real command execution against actualyay/parubinaries, generator logic, and the full test/lint suite — is verified as described above.Validation
cargo test --verbose(full workspace, rebased on currentmain): 153 tests pass (up from 145 onmainbefore this PR — 8 new unit tests for the-Pcparsers).cargo fmt -p warp-command-signatures -p warp-completion-metadata --check: clean.cargo clippy -p warp-command-signatures -p warp-completion-metadata --all-targets --all-features -- -D warnings: clean.npm run format:check: clean.Deviations from repo convention
factory/yay-paru-completions-fixesrather than this repo'sapp-####/command-spec-<command>Linear convention, since this traces back to GitHub issue Yay doesn't get the autocompletions packages while typing TAB like pacman does warp#5177, not a Linear ticket.Known gap: paru CLI has drifted further than this spec reflects
While verifying, I found
paru.json(in #334) is modeled mostly on paru'scompletions/fishscript, which was last updated 2025-10-06 (commit46e39bb, "Add pkgbuild repos to -Sl completion"). paru's actual CLI has moved on since then — the latest release, paru v2.1.0 (the version I actually built from AUR and verified-Pcoutput against, in the Docker container above), differs from what's modeled:-N/--repois gone; only bare--repoexists now.--mode <mode>,--pkgbuilds,-x/--regex.-L/--repoctland-C/--chrootctl(both modeled inparu.json) no longer appear inparu --helpat all — they may have been removed or renamed upstream.This is out of scope for this fix (only the
-Pcparsing and-i/--installplacement were flagged), so I leftparu.json's other operations as-is rather than risk introducing new errors with an unrequested rewrite. Recorded here as a known gap for a possible follow-up.