Problem or Use Case

Termux: make hermes update reuse pip cache before rebuilding Python dependencies

Summary

On Termux, hermes update appears to reinstall Python dependencies on every run, even when nothing relevant changed. I would prefer pip to reuse existing cache/wheels first, instead of triggering repeated source builds for packages that were already built successfully before. On my device this can take about an hour, so the downtime is noticeable.

Why this is a problem

Termux often has fewer prebuilt wheels than desktop platforms, so source builds are expected when Hermes dependencies change or when Python/ABI changes after pkg upgrade. But when none of those changed, rebuilding everything again is unnecessarily expensive and slow.

Observed behavior

hermes update runs the Python dependency install path unconditionally, so the logs often show repeated build / build wheel work.

Expected behavior

If the dependency set and environment have not changed, I would prefer hermes update to let pip reuse existing cache/wheels first instead of forcing a fresh rebuild.

Likely source of the behavior

The update flow in hermes_cli/main.py re-runs Python dependency installation during hermes update, which means pip does not get a chance to reuse what is already available locally.

Environment

• Hermes Agent on Termux / Android
• Python dependencies installed via pip install -e '.[termux]' -c constraints-termux.txt

Impact

This makes hermes update much slower than it needs to be on Android devices and wastes CPU/battery on repeated rebuilds of unchanged dependencies.

Proposed Solution

Suggested fix

Let pip try cache/wheel reuse first and only rebuild when it actually needs to. If a guard is needed, a lightweight stamp based on pyproject.toml, constraints-termux.txt, and the current Python version would be enough.

If Hermes does need to run a build path on Termux, it would also help to set ANDROID_API_LEVEL automatically from getprop ro.build.version.sdk in both hermes update and install flows, so users who forget to export it are still covered. The manual install docs already mention this, but having the CLI set it would reduce avoidable setup failures. If the value cannot be determined, failing fast with a clear error would also be fine.

Alternatives Considered

No response

Feature Type

Developer experience (tests, docs, CI)

Scope

Medium (few files, < 300 lines)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)