📦 Pip and Npm Belong on the Target too

Application developers reach for pip install or npm install without thinking. The moment that code needs to land on an embedded Linux target, the same one-line dependency install usually becomes a hand-written recipe per package. That's the friction the third walkthrough aims to remove.

The idea

Let the language's own package manager do the resolution. Capture its output. Ship it.

[yoe] now has units for three runtimes:

• Python — a virtual-environment class creates a venv named after the unit, runs pip install, and packages the resulting venv as an .apk that the target installs directly. Each application gets its own venv, so dependencies stay isolated.
• Node.js — npm install runs at build time, and node_modules/ rides along with the app in the same package.
• Bun — same flow as Node, but with the lighter-weight Zig-based runtime. Worth a look if a smaller footprint than full Node on the target is the goal.

The unit author writes the same dependency manifest as on a laptop — requirements.txt, package.json. The build system handles the rest.

Why this matters

Two of the goals in Hello, [yoe] and What a Modern Embedded Linux Build System Could Look Like were: don't reinvent dependency resolution, and don't force application developers to learn a second packaging system to ship what they already wrote. This is what that looks like in practice — pip, npm, and bun composed in rather than replaced.

What's next

Rust and Zig units are queued up next, along with Python ML workloads where the dependency graph gets a lot more interesting. The YouTube playlist is the place to subscribe for new walkthroughs as features land.

What development workflow would be most useful to see demoed next? Open a discussion or send a note.