Hello!
I've been playing with plannotator for the past few days and really enjoy it! However, when trying the review guide feature, it keeps resulting in crashes because of pi extensions1 also running. This made me notice that the way pi is spawned currently loads extensions defined in the ~/.pi/agent/settings.json.
My first thought was to "simply" disable all extensions in that case, but then pi doesn't have access to models registered in providers in extensions.
What do you think about allowing the user to configure which extensions to load when within plannotator? I didn't fully research the best way to do this, but wanted to ask first if this is something you'd be interested in before digging a bit more on what would be the ux, how / where to store, what happens when new extensions are configured in the settings, etc. (see session below, linked to a naive plan by kimi on how to implement this).
No worries if not something you think is worth pursuing!
Research session: https://pi.dev/session/#fb28ae92ae3b3378c17e309e5c071fdc&leafId=32a07f8a&targetId=b7f20f0e
Hello!
I've been playing with plannotator for the past few days and really enjoy it! However, when trying the review guide feature, it keeps resulting in crashes because of pi extensions1 also running. This made me notice that the way
piis spawned currently loads extensions defined in the~/.pi/agent/settings.json.My first thought was to "simply" disable all extensions in that case, but then pi doesn't have access to models registered in providers in extensions.
What do you think about allowing the user to configure which extensions to load when within plannotator? I didn't fully research the best way to do this, but wanted to ask first if this is something you'd be interested in before digging a bit more on what would be the ux, how / where to store, what happens when new extensions are configured in the settings, etc. (see session below, linked to a naive plan by kimi on how to implement this).
No worries if not something you think is worth pursuing!
Research session: https://pi.dev/session/#fb28ae92ae3b3378c17e309e5c071fdc&leafId=32a07f8a&targetId=b7f20f0e
Footnotes
In this case, it was a pi extension that names the current session and was accessing stale
ctxbecause it expects the session to continue after the first turn, which is not the case with-p PROMPT. ↩