How do you install new packages?

[lyasm25]

Usually you would just do pi install {package_name}, how would you do that so it installs to little-coder's pi?

[kellyinvestor]

Would love to see little-coder reworked into a Pi package itself.

[black-snow]

Would love to see little-coder reworked into a Pi package itself.

This was actually what I expected when I got here.

[itayinbarr]

Good question — the answer's a little non-obvious, so worth spelling out.

little-coder launches pi with --no-extensions and then loads only the extensions it bundles (each .pi/extensions/*/index.ts, passed explicitly as --extension). In that mode pi loads only the explicit -e paths and skips anything registered in its settings. So pi install <pkg> — which writes the package into pi's settings.json — won't show up inside little-coder. That's deliberate: the bundled set is curated for small-model fit, and I want every launch to be the same set rather than picking up whatever's installed globally.

Two ways to actually add one:

• Per launch (nothing to install): little-coder -e /abs/path/to/ext/index.ts. little-coder forwards extra args straight through to pi, and explicit -e paths load even under --no-extensions. Repeat the flag for several.
• Permanent: drop the extension into the installed package's .pi/extensions/<name>/ (a directory with an index.ts); the launcher auto-discovers every such directory on startup. Caveat: it lives inside the npm package, so npm i -g little-coder@latest overwrites it on upgrade.

(I just corrected the README, which oversold the pi install / settings route — thanks for the nudge.)

@kellyinvestor @black-snow — on reworking it into a pi package itself: I get the instinct, and the reason it's built on pi is exactly that — to keep the parts modular and accessible. Every mechanism is its own small, readable extension you can lift, disable, or copy into your own pi. So the building blocks are very much "pi packages."

What can't collapse into a single installable plugin is the whole. The way I think about it: a pi install plugin extends a pi you control; little-coder contains a pi it controls. It runs pi with --no-extensions to isolate the curated set, replaces the system prompt, pins a known-good pi version per release, patches a couple of pi runtime behaviours on launch, and — most of all — intervenes in the control loop itself (thinking-budget caps, write/read guards, quality steering). A plugin can add to your pi; it can't tell your pi to disable everything else, swap its prompt, and reshape its agent loop. Those harness-level guarantees are what make it "just work" on a small local model, and they're the product — not an accident of packaging. If you want a specific piece in your own pi (an extension, the skills), point at it and I'll help — it's all Apache-2.0 and self-contained.

[black-snow]

Makes sense to me, thanks for the thorough answer.
Perhaps publish things that can be isolated as standalone pkg as well so folls can install and update them conveniently and then mix & match?

[itayinbarr]

Circling back on this, @black-snow — your suggestion here (publish the isolatable pieces as standalone packages so folks can install/update and mix & match) is now being explored: @dbmrq opened #62 to publish little-coder's extension/skill layer as a pi install-able package. One caveat I noted there — some of what little-coder does is applied by patching pi itself + launcher wiring, not pure extensions, so a package would be a curated subset rather than the whole thing — but the mix-and-match direction you asked about is very much on the table. Thanks for planting the idea early.