Skip to content

Fix yay/paru completion specs: -Pc field separators and -B/--build option placement - #336

Merged
acarl005 merged 2 commits into
mainfrom
factory/yay-paru-completions-fixes
Aug 14, 2026
Merged

Fix yay/paru completion specs: -Pc field separators and -B/--build option placement#336
acarl005 merged 2 commits into
mainfrom
factory/yay-paru-completions-fixes

Conversation

@warp-agent-staging

@warp-agent-staging warp-agent-staging Bot commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Summary

Follow-up to #334 (merged as 79e45eb), which added completion specs for yay and paru (fixing warpdotdev/warp#5177) but had two defects caught in post-merge review. This PR fixes them on top of current main.

Do not bump the warp-command-signatures rev pin in warpdotdev/warp/Cargo.toml past this PR. #334's parser bug is on main right now but hasn't reached any user yet, because warp's Cargo.toml is still pinned to the older rev 32a7fd5. 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: -Pc output is not bare package names

Neither yay -Pc nor paru -Pc print bare package names, and they don't even share a separator:

  • yay writes tab-separated name\tsource lines (pkg/completion/completion.go's createAURList/createRepoList: pkgName+"\tAUR\n", pkg.Name()+"\t"+pkg.DB().Name()+"\n").
  • paru writes space-separated name source lines (src/completion.rs's repo_list/pkgbuild_list/aur_list: name, b" ", db.name(), b"\n", and line, b" AUR\n").

The merged version treated each whole line as the insertable package name, so completing yay -S btrfs- would have inserted btrfs-progs\tAUR literally — worse than the original bug.

Added a parse_package_list function 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 new yay_tests.rs / paru_tests.rs with 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-bin and paru from AUR inside an archlinux:latest container to capture actual -Pc output:

  • 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 AUR packages.gz fetch/decode inside the sandboxed container — paru's own cache-refresh path), rather than a clean name AUR sample. 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_packages and list_all_pkg_tar_files_in_cwd are unchanged logic moved from the pre-existing pacman.rs (not new parsing), so there was nothing new to re-verify there.

2. -i/--install was modeled on the wrong operation

Both specs had -i/--install under -U/--upgrade, which doesn't accept it. It's documented as a -B/--build option in both tools:

  • yay's man page: "BUILD OPTIONS (APPLY TO -B AND --build): -i, --install — Build and install a PKGBUILD in a given directory."
  • paru's src/help.rs: "Build specific options: -i --install — Install package as well as building."

Removed -i/--install from -U/--upgrade in both yay.json and paru.json. Added it to yay's existing -B/--build entries. 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-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-warp skills ask for. Stating that plainly rather than approximating it. Everything else — real command execution against actual yay/paru binaries, generator logic, and the full test/lint suite — is verified as described above.

Validation

  • cargo test --verbose (full workspace, rebased on current main): 153 tests pass (up from 145 on main before this PR — 8 new unit tests for the -Pc parsers).
  • 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

Known gap: paru CLI has drifted further than this spec reflects

While verifying, I found paru.json (in #334) is modeled mostly on paru's completions/fish script, which was last updated 2025-10-06 (commit 46e39bb, "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 -Pc output against, in the Docker container above), differs from what's modeled:

  • -N/--repo is gone; only bare --repo exists now.
  • New top-level options exist that aren't modeled: --mode <mode>, --pkgbuilds, -x/--regex.
  • -L/--repoctl and -C/--chrootctl (both modeled in paru.json) no longer appear in paru --help at all — they may have been removed or renamed upstream.

This is out of scope for this fix (only the -Pc parsing and -i/--install placement were flagged), so I left paru.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.

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>

@warp-agent-staging warp-agent-staging Bot left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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-spec guidance 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 -Pc output captured from yay and paru built in an archlinux container, 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 confirm yay -S <prefix> and paru -S <prefix> in Warp before merge.
  • paru.json was largely derived from paru's shipped fish completion script, and current paru has drifted from it: -N/--repo is replaced by a bare --repo, --mode, --pkgbuilds, and -x are new, and -L/--repoctl and -C/--chrootctl no 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 over paru.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
warp-agent-staging Bot marked this pull request as ready for review August 14, 2026 00:14
@warp-agent-staging
warp-agent-staging Bot requested a review from acarl005 August 14, 2026 00:14
@oz-for-oss

oz-for-oss Bot commented Aug 14, 2026

Copy link
Copy Markdown

@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 /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

@oz-for-oss oz-for-oss Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
@acarl005
acarl005 merged commit 99c637f into main Aug 14, 2026
8 checks passed
@acarl005 acarl005 self-assigned this Aug 14, 2026
@acarl005
acarl005 deleted the factory/yay-paru-completions-fixes branch August 14, 2026 00:34
warp-agent-staging Bot pushed a commit to warpdotdev/warp that referenced this pull request Aug 14, 2026
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>
acarl005 pushed a commit to warpdotdev/warp that referenced this pull request Aug 14, 2026
…--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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants