Repository navigation
[Suggestion]: Add a global config file for pi-fff #789
Description
Activity
[triage-bot] FEATURE REQUEST: shape is correct, claims verified against
main(459ebcd). Not implementing — see last line.All five settings are resolved once at extension-registration time, so a file loader has exactly one insertion point:
packages/pi-fff/src/index.ts:302-306— mode (flag > env >"tools-and-ui")packages/pi-fff/src/index.ts:311-317— frecency/history db (flag > env >resolveDbPathsdiscovery)packages/pi-fff/src/index.ts:320-340—resolveBoolOptfor root/home scanning
PI_FFF_MULTIGREP(packages/pi-fff/src/index.ts:1011) is correctly excluded — source comment above it says the tool is being removed.Two things for the PR:
- There is no
getAgentDir()in the extension API surface this repo consumes —grep -rn getAgentDirreturns nothing. pi-fff already resolves the dir itself atpackages/pi-fff/src/paths.ts:55-57:
function piDataDir(): string { return process.env.PI_CODING_AGENT_DIR ?? path.join(HOME_DIR, ".pi", "agent"); }
Reuse that (export it), do not add a new dependency on a pi API that is not there.
- This runs on every
pistartup before any tool is registered. OnereadFileSyncin a try/catch plus hand-written type checks. No schema library, no async, no extrastatSyncprobe — ENOENT from the read is the missing-file no-op.
@dmtrKovalenko — reporter has this in a fork and offered the PR. Needs your ack on the file name/location before they spend the effort; not opening a competing bot PR.
Honk-Honk 🪿Yeah that makes sense. Feel free to open a PR just a favor I’d like to ask is yo have a single function to retrieve the configuration value that will look everywhere
Thanks. I updated the implementation to export and reuse the existing
piDataDir(), removed the runtimegetAgentDir()import, and put flag/env/file/fallback lookup behind onegetConfigValue()function.The loader still does one synchronous read with hand-written validation. The pi-fff tests, typecheck, and focused Biome check pass.
PR: #790
Which fff frontend?
@ff-labs/pi-fffWhat problem are you trying to solve?
pi-fff has five public startup settings, but keeping any of them across launches currently means setting environment variables or wrapping every
piinvocation with flags. This is especially awkward foroverride, which has to be known before the extension registers its tools.Pi deliberately does not accept extension-owned keys in its core
settings.json. Its maintainer recommends that extensions keep their own files undergetAgentDir()instead: earendil-works/pi#1184Proposed solution
Read
<getAgentDir()>/pi-fff.jsonbefore registering tools. For example:{ "mode": "override", "frecencyDbPath": "/path/to/frecency", "historyDbPath": "/path/to/history", "enableFsRootScanning": false, "enableHomeDirScanning": true }This covers every currently documented startup option. Existing behavior stays ahead of the file:
A missing file should be a no-op. Malformed JSON, unknown keys, and wrong value types should stop the extension from loading with a path-specific error rather than silently falling back.
/fff-modewould keep its current session behavior and would not rewrite a global file implicitly.I think the first version should be global only.
modeis needed during tool registration, and the extension API does not expose trusted project configuration at that point. I would also leave out the hiddenPI_FFF_MULTIGREPswitch: it is not a documented setting, and the source already marks that tool for removal.I have this implemented and covered in a fork, including loader validation, all five settings, and flag/env precedence. Happy to send the PR if this shape works for you.