Skip to content

Feature: allow to overwrite the pi binary to use#9

Merged
pablopunk merged 1 commit into
pablopunk:mainfrom
f4z3r:feat/command
May 8, 2026
Merged

Feature: allow to overwrite the pi binary to use#9
pablopunk merged 1 commit into
pablopunk:mainfrom
f4z3r:feat/command

Conversation

@f4z3r

@f4z3r f4z3r commented May 8, 2026

Copy link
Copy Markdown
Contributor

First of all, thanks for the plugin. Just the kind of minimal thing I love.

I am using a wrapper for pi in order to isolate the agent on my system to reduce blast radius in case it starts going crazy. Especially since I don't want it to pollute my system with stuff when it autonomously installs tools that it needs.

Therefore it would be great if the binary/command that is used to start pi could be customized. I initially tried to achieve this simply using a shell alias. However, this is not ideal as I want a different wrapper for nvim than for the alias that I use in the shell. This quickly becomes messy, so I reverted to this small change.

I am opening this PR as I am guessing others might want similar flexibility.

Summary by CodeRabbit

  • New Features

    • Added an optional "binary" configuration to let users specify a custom pi executable or wrapper (defaults to "pi"). Accepts a string or an array of strings for flexible invocation.
  • Documentation

    • Updated configuration docs and examples to show the new "binary" option and its usage.

@coderabbitai

coderabbitai Bot commented May 8, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Rate limit exceeded

@f4z3r has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 7 minutes and 25 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 189b9984-1d4f-43b4-a137-fd67b0dce780

📥 Commits

Reviewing files that changed from the base of the PR and between 08356dd and 263a1dc.

📒 Files selected for processing (3)
  • README.md
  • lua/pi/config.lua
  • lua/pi/init.lua

Walkthrough

This PR adds a new optional binary configuration setting to pi.nvim that allows users to specify custom pi binary installations or wrappers. The configuration defaults to "pi" and accepts either a string or a table/array of strings. Changes update configuration defaults and validation in lua/pi/config.lua, command construction in lua/pi/init.lua to use the configured binary/argv, and README examples/documentation to document the new setting.

Possibly related PRs

  • pablopunk/pi.nvim#7: Also modifies lua/pi/config.lua and lua/pi/init.lua to add configuration options and related validation in the same code paths.
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The pull request title accurately describes the main feature being added: allowing customization of the pi binary used by the plugin through a new configuration option.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

  • Generate code and open pull requests
  • Plan features and break down work
  • Investigate incidents and troubleshoot customer tickets together
  • Automate recurring tasks and respond to alerts with triggers
  • Summarize progress and report instantly

Built for teams:

  • Shared memory across your entire org—no repeating context
  • Per-thread sandboxes to safely plan and execute work
  • Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai 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.

Actionable comments posted: 3

🧹 Nitpick comments (1)
lua/pi/init.lua (1)

38-38: 💤 Low value

Dead-code fallback — cfg.binary is always truthy.

M.defaults.binary = "pi" guarantees cfg.binary is never nil or falsy after config.setup() runs (and values is initialized from M.defaults even before setup is called). The local binary = { "pi" } line and its surrounding if cfg.binary then branch are therefore unreachable dead code. Consider removing the fallback and unwrapping the branch for clarity.

♻️ Proposed simplification
-  local binary = { "pi" }
-  if cfg.binary then
-    if type(cfg.binary) == "table" then
-      binary = vim.list_extend({}, cfg.binary)
-    else
-      binary = { cfg.binary }
-    end
-  end
+  local binary
+  if type(cfg.binary) == "table" then
+    binary = vim.list_extend({}, cfg.binary)
+  else
+    binary = { cfg.binary }
+  end
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lua/pi/init.lua` at line 38, The branch that sets a fallback local binary = {
"pi" } is dead because M.defaults.binary = "pi" (and config.setup()/values
initialization) makes cfg.binary always truthy; remove the unreachable if
cfg.binary then ... end block and instead directly use cfg.binary where needed
(or assign local binary = cfg.binary without the conditional); update any
references to the removed local to use cfg.binary so the code is simpler and no
fallback duplication remains.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@lua/pi/config.lua`:
- Around line 41-43: The validation for opts.binary in config.lua currently only
checks that opts.binary is a string or table but doesn't validate table element
types; update the check so when type(opts.binary) == "table" you iterate its
elements and ensure each element is a string (and error with the same message
"pi.nvim: binary must be a string or list of strings" if any element is not a
string), so invalid values like {123, true} fail validation before runtime.

In `@lua/pi/init.lua`:
- Around line 40-46: The code currently assigns binary = cfg.binary and then
calls vim.list_extend(binary, ...) which mutates cfg.binary; to fix, ensure you
shallow-copy cfg.binary before extending it (e.g., create a new table local
binary = vim.deepcopy(cfg.binary) or iterate to copy elements) so
vim.list_extend operates on a fresh table; update the code paths that set binary
from cfg.binary (the branch that assigns binary = cfg.binary) so the subsequent
vim.list_extend call does not modify cfg.binary and then build cmd from that
copied binary.

In `@README.md`:
- Line 80: The `binary` table description has a truncated sentence; update the
`binary` row so the clause completes the thought (e.g., change the fragment
"When omitted or set to `\"pi\"`." to a full sentence like "When omitted or set
to `\"pi\"`, the runtime defaults to the system `pi` binary.") — edit the
`binary` entry so it clearly states the default behavior and accepted types
(string or array of strings) referenced by the `binary` field.

---

Nitpick comments:
In `@lua/pi/init.lua`:
- Line 38: The branch that sets a fallback local binary = { "pi" } is dead
because M.defaults.binary = "pi" (and config.setup()/values initialization)
makes cfg.binary always truthy; remove the unreachable if cfg.binary then ...
end block and instead directly use cfg.binary where needed (or assign local
binary = cfg.binary without the conditional); update any references to the
removed local to use cfg.binary so the code is simpler and no fallback
duplication remains.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: dddf9dfb-a229-46ad-9700-465a9fa52c34

📥 Commits

Reviewing files that changed from the base of the PR and between a318805 and fbce0a1.

📒 Files selected for processing (3)
  • README.md
  • lua/pi/config.lua
  • lua/pi/init.lua

Comment thread lua/pi/config.lua
Comment thread lua/pi/init.lua
Comment thread README.md Outdated
@f4z3r

f4z3r commented May 8, 2026

Copy link
Copy Markdown
Contributor Author

🧹 Nitpick comments (1)

lua/pi/init.lua (1)> 38-38: 💤 Low value

Dead-code fallback — cfg.binary is always truthy.
M.defaults.binary = "pi" guarantees cfg.binary is never nil or falsy after config.setup() runs (and values is initialized from M.defaults even before setup is called). The local binary = { "pi" } line and its surrounding if cfg.binary then branch are therefore unreachable dead code. Consider removing the fallback and unwrapping the branch for clarity.

While this is the case, I am leaving it. I did this to align with how other configuration values are handled, such as thinking, which is also guaranteed to be provided but contains a guard in init.lua.

@pablopunk pablopunk left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

yeah this is a no brainer, very good to have. Can you update the config example in the Readme? I try to keep all configs there

require("pi").setup({
  -- ...
  pi = "~/.bin/pi", -- or { "env", "FOO=1", "pi-wrapper" }

@coderabbitai coderabbitai 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.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@README.md`:
- Line 58: Update the README example to use the correct config key name: replace
the shown `pi = "~/.bin/pi"` entry with `binary = "~/.bin/pi"` (or the
equivalent env wrapper form) so the documented option matches the implemented
configuration key `binary` instead of the nonexistent `pi`.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c0a08e3a-d41e-4df2-ab22-0cec9d2beb5f

📥 Commits

Reviewing files that changed from the base of the PR and between fbce0a1 and 08356dd.

📒 Files selected for processing (3)
  • README.md
  • lua/pi/config.lua
  • lua/pi/init.lua
🚧 Files skipped from review as they are similar to previous changes (2)
  • lua/pi/config.lua
  • lua/pi/init.lua

Comment thread README.md Outdated

```lua
require("pi").setup({
pi = "~/.bin/pi", -- or { "env", "FOO=1", "pi-wrapper" }

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use the correct config key in the setup example (binary, not pi).

Line 58 documents pi = ..., but the option introduced by this PR is binary. As written, users will configure a non-existent key.

Suggested doc fix
 require("pi").setup({
-  pi = "~/.bin/pi", -- or { "env", "FOO=1", "pi-wrapper" }
+  binary = "~/.bin/pi", -- or { "env", "FOO=1", "pi-wrapper" }
   provider = "openrouter",
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
pi = "~/.bin/pi", -- or { "env", "FOO=1", "pi-wrapper" }
binary = "~/.bin/pi", -- or { "env", "FOO=1", "pi-wrapper" }
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@README.md` at line 58, Update the README example to use the correct config
key name: replace the shown `pi = "~/.bin/pi"` entry with `binary = "~/.bin/pi"`
(or the equivalent env wrapper form) so the documented option matches the
implemented configuration key `binary` instead of the nonexistent `pi`.

Signed-off-by: Jakob Beckmann <f4z3r-github@pm.me>
@pablopunk

Copy link
Copy Markdown
Owner

thankssssss

@pablopunk pablopunk merged commit dcd3e5e into pablopunk:main May 8, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants